[#37892] 配列の重複検出用Hashの使いまわし — wanabe <s.wanabe@...>
ワナベと申します。
[#37898] [Bug #1105] Ruby1.9でのrescue節の例外ハンドラのマッチの処理 — Tatsuji Kawai <redmine@...>
Bug #1105: Ruby1.9でのrescue節の例外ハンドラのマッチの処理
[#37910] [Bug:1.9] lack consistency in hash iteration — Yusuke ENDOH <mame@...>
遠藤です。
まつもと ゆきひろです
[#37918] [BUG: 1.9] encoding warning — SASADA Koichi <ko1@...>
ささだです.
[#37921] [Feature:trunk] with_index_from — Yusuke ENDOH <mame@...>
遠藤です。
At Thu, 5 Feb 2009 23:18:49 +0900,
遠藤です。
At Fri, 6 Feb 2009 00:58:59 +0900,
[#37936] zombie processes by drb tests — Tanaka Akira <akr@...>
OpenBSD で、test-all をすると、drb のところで、テストに 100
咳といいます。
[#37956] proposal: Module#method_adding — SASADA Koichi <ko1@...>
ささだです.
[#37959] [Bug:trunk] I can modify literals — Yusuke ENDOH <mame@...>
遠藤です。
[#37980] Re: [ruby-changes:10687] Ruby:r22250 (trunk): * iseq.c (simple_default_value): allow plain strings as default — SASADA Koichi <ko1@...>
ささだです.
[#37995] Add POSTARG support to rb_scan_args() — Akinori MUSHA <akinori.musha@...>
rb_scan_args()をPOSTARG対応にするパッチです。
[#37998] [Feature:1.9] {Array,Enumerable}#uniq_by, #uniq_by! — Nobuyoshi Nakada <nobu@...>
なかだです。
[#38005] Is URI.decode() broken? — MOROHASHI Kyosuke <moronatural@...>
もろはしです。いつもお世話になっております。
なかだです。
成瀬です、
xibbarこと藤岡です。
成瀬です。
NARUSE, Yui さんは書きました:
成瀬です。
(2009年03月03日 22:45), NARUSE, Yui さんは書きました:
成瀬です。
In article <4A9E44DD.6050706@airemix.jp>,
成瀬です。
小崎@思いつきを適当に書いてみるテスト
In article <20090907091830.2C7A.A69D9226@jp.fujitsu.com>,
> In article <20090907091830.2C7A.A69D9226@jp.fujitsu.com>,
2009/09/07 14:38, Tanaka Akira wrote:
In article <4AA5EA67.1040504@airemix.jp>,
[#38007] [Feature #1159] StringScanner に文字ベースでのインデックスを返すメソッドがほしい — Akira Matsuda <redmine@...>
Feature #1159: StringScanner に文字ベースでのインデックスを返すメソッドがほしい
[#38018] circular require in openssl — Tanaka Akira <akr@...>
以下のように、openssl には環状の require があり、警告が出ます。
In article <87vdrcul7y.fsf@fsij.org>,
まつもと ゆきひろです
In article <E1LYyoE-0005P0-Hi@x61.netlab.jp>,
[#38022] ENCODING_FIXED と ENCODING_NONE の廃止 — "NARUSE, Yui" <naruse@...>
成瀬です。
In article <49986A0A.5060602@airemix.jp>,
成瀬です。
In article <49995412.6040000@airemix.jp>,
[#38048] Add option hash support to rb_scan_args() — "Akinori MUSHA" <knu@...>
rb_scan_args() にoption hash対応を組み込むのはどうでしょうか。
[#38067] Re: [ruby-cvs:29304] Ruby:r22086 (trunk): * ruby.c (process_options): set initial default_external before -r. — "Yugui (Yuki Sonoda)" <yugui@...>
Yuguiです。
[#38075] [Bug #1198] corrupted iteratoin during "enum_for :inject" — Shyouhei Urabe <redmine@...>
Bug #1198: corrupted iteratoin during "enum_for :inject"
[#38080] [Feature:trunk] nested loop construct — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
ささだです.
[#38096] 多重代入やメソッド引数の展開でto_aが呼ばれます — nagachika <nagachika00@...>
nagachika と申します。
前田です。
まつもと ゆきひろです
前田です。
In article <704d5db90907141754p285e6e51xdd3208b27d556906@mail.gmail.com>,
[#38098] ブロック引数と括弧・引数なしsuper — Shugo Maeda <shugo@...>
前田です。
まつもと ゆきひろです
[ruby-dev:38001] Re: proposal: Module#method_adding
永井@知能.九工大です.
From: Urabe Shyouhei <shyouhei@ruby-lang.org>
Subject: [ruby-dev:37989] Re: proposal: Module#method_adding
Date: Fri, 13 Feb 2009 12:19:50 +0900
Message-ID: <4994E72A.9070301@ruby-lang.org>
> フックが呼ばれる度にMethodオブジェクトを生成するというのが著しく非効率
> という話を聞きます。
> method_addedが少々遅いくらいがどうした、というのも見識の一つとは思いますが。
method_added が定義されていない限りは
Method オブジェクトは作らなくてもいいですよね.
Method の有無を確認した後で Method オブジェクトを作ればいいはずです.
method_added の有無を調べるステップはいずれにせよ一度は必要なので,
先に有無を調べておくこと自体はコストアップにはならないと思います.
method_added を本当に呼ぶことはさほど頻繁にはないでしょうから,
本当に呼ぶ必要があるときに少しくらい遅くても問題はないでしょう.
symbol だけを受け取る method_adding/method_added の場合には,
method_adding では定義される予定の method が得られず,
method_added では再定義前の method が得られません.
method_adding/method_added の両方での操作が必要になるかもしれません.
その場合,旧 method の Method オブジェクトを
method_adding から method_added に引きわたすための変数も
用意しなければならないかもしれません.
一つのメソッドで両方の Method オブジェクトを受け取れるなら,
ユーザは楽ができます.(^_^)
とはいえ,method 定義時に内部で
(1) hook の有無を検査
(2) hook が存在したなら,旧メソッドの Method オブジェクトを生成
(3) method を定義
(4) hook が存在したなら,新メソッドの Method オブジェクトを生成して
hook の呼び出し
というステップを経なければいけないのは面倒なので,
method_adding と method_added とを組み合わせてなんとかできるなら
それで十分だろうという主張も理解できます.
私は Method オブジェクトを受け取れる方が嬉しいように思えますが,
「そうあるべき」とまで強くは主張しません.
判断はお任せします.
# ...って,無責任 (^_^;
--
永井 秀利 (nagai@ai.kyutech.ac.jp)
九州工業大学 大学院情報工学研究院 知能情報工学研究系