[#41531] [Bug #3385] ext/dbm: accept various version of db — Takahiro Kambe <redmine@...>
Bug #3385: ext/dbm: accept various version of db
2010年6月3日23:38 Takahiro Kambe <redmine@ruby-lang.org>:
2011年11月12日8:14 Tanaka Akira <akr@fsij.org>:
[#41536] RUBY_DEBUG=gc_stress [FATAL] failed to allocate memory — Tanaka Akira <akr@...>
コンパイル時に RUBY_DEBUG_ENV というマクロを定義しておくと、
[#41543] [Bug #3398] 1.9.2 SEGV during test-all — Yuki Sonoda <redmine@...>
Bug #3398: 1.9.2 SEGV during test-all
[#41597] [Bug #3433] Error that occurs by BasicSocket#sendmsg — Masaya Tarui <redmine@...>
Bug #3433: Error that occurs by BasicSocket#sendmsg
[#41600] 質問・提案:cgi.rbの後継となるライブラリについて — Dice <tetradice@...>
Diceです。cgi.rbの後継ライブラリについて質問させてください。
藤岡です。
かくたにです。
藤岡さん、かくたにさん、返信ありがとうございます。
藤岡です。
Diceです。藤岡さん、返信ありがとうございます。
[#41610] [Bug #3443] requireが遅くなる — Yusuke Endoh <redmine@...>
Bug #3443: requireが遅くなる
[#41623] [Feature:trunk] argument delegation — Nobuyoshi Nakada <nobu@...>
なかだです。
遠藤です。
まつもと ゆきひろです
前田です。
[#41672] [Bug #3463] 1.9.2-preview3 で [BUG] gc_sweep(): unknown data type 0x0 — Tomoyuki Chikanaga <redmine@...>
チケット #3463 が更新されました。 (by Tomoyuki Chikanaga)
[#41674] [Bug #3464] win32ole failure load TYPELIB on mswin64 vista — sakiyama shin <redmine@...>
Bug #3464: win32ole failure load TYPELIB on mswin64 vista
[#41702] WIN32OLE_METHOD offset_vtbl — kuwamoto shintaro <beuniv@...>
こんばんわ
助田です。
こんにちは、なかむら(う)です。
助田です。
artonです。
2010/6/24 arton <artonx@yahoo.co.jp>:
[#41705] [Bug #3471][Rejected] ./miniruby sample/test.rbで1NotOK — Shyouhei Urabe <redmine@...>
チケット #3471 が更新されました。 (by Shyouhei Urabe)
2010年6月24日16:53 Shyouhei Urabe <redmine@ruby-lang.org>:
[#41711] [Bug #3473] make clear-installed-list — Usaku NAKAMURA <redmine@...>
Bug #3473: make clear-installed-list
[#41730] (ruby/tk) ruby_1_9_2 への backport — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
[#41752] [Bug #3490][Assigned] test_pack_utf8 failure on mswin64 — Yusuke Endoh <redmine@...>
チケット #3490 が更新されました。 (by Yusuke Endoh)
[#41760] Hash[] の引数が Array の場合の振る舞い — とみたまさひろ <tommy@...>
とみたです。
[ruby-dev:41631] Re: [Feature:trunk] argument delegation
2010年6月17日6:31 Yukihiro Matsumoto <matz@ruby-lang.org>:
> |(1) ブロックを引き継がせたいだけ (引数は変えたい) ときに不便
> (1) については、ブロックを引き継がせたい時には、明示的にブロッ
> クを引き渡せばよい(ひとつのことをしたいときに、ひとつのこ
> とをすればよい。冗長性はない)ので、手当ての必要があるか
> どうか疑問です。今回の動機は「ひとつのことをするのに、ふ
> たつのことを書かないといけない」という冗長性ですから。
今回の話にはなぜか触れられていないんですが、
この機能の背景のひとつにはキーワード引数があるように思えます。
キーワード引数を加えたときに、キーワード引数が
普通の引数でもブロック引数でもないものとすると、
すべての引数を引き渡すのに 3つそれぞれについて引き渡さないといけません。
それを避けるためにキーワード引数を普通の引数の一部にするということにしたら、
反論が出まくって仕様がまとまらなかった、というのが私の認識です。
[ruby-talk:162431]
それならすべての引数を引き渡すための機能をつける、というアイデアを
[ruby-talk:162561] や [ruby-dev:30892] に書いたことがありますが、
その時点では反応を得られませんでした。
そういう流れで今回のを見ると、あり得る方向だと思うわけですが、
2つ懸念があります。
今は普通の引数とブロック引数のふたつしかないので、
ひとつを変えるなら、残りはひとつしかありません。
したがって、残りすべてを引き渡すのはひとつ書けば済みます。
しかし、キーワード引数が入るとみっつになるので、
ひとつを変えるなら、残りはふたつになります。
残りすべてを引き渡すのにふたつ書く必要が出てきます。
おそらくこれはうれしくないでしょう。
つまり、argument delegation はキーワード引数を入れるときに困る問題を解決する
かもしれないと思ったら、実際のところはあまり解決していない、というわけです。
> |(3) define_method でサポートできていない (将来的にされる予定はある?)
> (3) 将来的には、define_methodでもサポートされるべきだと思いま
> す。できてないのは実装上の制約だと思ってください。
もうひとつは define_method や lambda との関連です。
... という構文には名前が入っていないので、
def f(a)
lambda {|b|
g(...)
}
end
としたときに ... はどの引数を指すのか不明です。
仕様としてどちらかに固定することはできるでしょうが、
プログラマが選べるような構文にはなっていません。
そのうち、選べるようにする構文が要求されるようになるんじゃないでしょうか。
--
[田中 哲][たなか あきら][Tanaka Akira]