[#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:41641] Re: [Feature:trunk] argument delegation
前田です。
2010年6月17日14:53 Yukihiro Matsumoto <matz@ruby-lang.org>:
> |argument delegationについてはまだ態度を決めかねているのですが、
> |super(...)が導入されたら、(警告を出すなどの移行ステップを経て)
> |括弧なしsuperはsuper()と同じ意味にしてしまってはどうでしょうか。
>
> うーん、superがsuper()の意味であってうれしいのは、
>
> * ルールが少なくなる
> * 無引数superの呼び出しが十分に多い
>
> のいずれかだと思うのですが、前者は結局はRubyの設計では優先度
> が低い「一貫性」を高めるということなので、この際「うれしい」
> とは評価しません。
強いていえば前者ですが、ルールが少なくなることそのものがうれしい
のではなくて、通常のメソッド呼出しだと()を付けなくてもよいのに、
superのときだけ引数がないのに()を付けないといけないのが(見た目
的に)気持ち悪い、という理由です。
> 後者ですが、これが実際的にうれしいのは
>
> * superを含むメソッドが引数を1個以上受け取り
> * superにはひとつも渡さない
>
> というケースだけで、
私の経験では、initializeをオーバーライドするときにsuper()と書かないと
いけなくて気持ち悪いと感じることが結構ありました。
ちなみに標準添付ライブラリにおけるsuper/super()の利用箇所を調べたところ
super: 391箇所
super(): 292箇所
という結果でした。意外といい勝負じゃないでしょうか。
> superの使い道のうち多くを含む(と思われる)
>
> * superを含むメソッドが引数を1個以上受け取り
> * superにそのまま渡す
>
> 場合、これまでsuperだけですんだものをsuper(...)と書かねばなら
> ず、ちっともうれしくありません。
5文字の節約が重要になるほどよく使う機能でもないと思うので、
短い記述で済むことよりも、他の機能との類推でsuperの挙動を
推測できることの方が利点が大きいように思います。
ただ、互換性の問題もある(既存のスクリプトは機械的に置換できる
んじゃないかと思いますが)ので、それほど強くは主張しません。
> |superではブロック引数への代入が反映されない動作になっていますが、
> |argument delegationではどうなりますか?
> |
> | def foo(&b)
> | b = lambda { puts "lambda in foo" }
> | bar(...)
> | end
> |
> |というケースの話ですが。
>
> 「superと同じ動作」というのが基本だと思います。本当は、通常
> 引数も代入が反映されないようにしたいのですが、YARVの実装だと
> 難しいと聞いたような気がします。
性能上の理由ということで了解しました。
# 個人的には、引数に代入するのは悪いスタイルだと思ってるので、どっちでも
# いいんですけど。
--
Shugo Maeda