[#39845] Re: [ruby-cvs:33238] Ruby:r26022 (trunk): * marshal.c (w_object): dump instance variables when using — Tanaka Akira <akr@...>
2009/12/5 <nobu@ruby-lang.org>:
3 messages
2009/12/06
[#39846] [Bug #2447] reduce GC pressure by symbol table without String instance — Yusuke Endoh <redmine@...>
Bug #2447: reduce GC pressure by symbol table without String instance
5 messages
2009/12/06
[#39847] stable find.rb — Tanaka Akira <akr@...>
44OH44Kj44Os44Kv44OI44Oq44KS5YaN5biw55qE44Gr44Gf44Gp44Gj44Gf57WQ5p6c44KS5q+U
5 messages
2009/12/06
[#39851] Time.now + str と #to_r — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
9 messages
2009/12/07
[#39852] Re: Time.now + str と #to_r
— "NARUSE, Yui" <naruse@...>
2009/12/07
成瀬です。
[#39855] [RubySpec #2460] RubySpecでFiberのSpecがおちる — 三村 益隆 <redmine@...>
RubySpec #2460: RubySpecでFiberのSpecがおちる
4 messages
2009/12/08
[#39863] [Feature #2471] want to choose a GC algorithm — _ wanabe <redmine@...>
Feature #2471: want to choose a GC algorithm
8 messages
2009/12/09
[#39874] faster Enumerator#each by rb_block_call with current block — Yusuke ENDOH <mame@...>
遠藤です。
7 messages
2009/12/13
[#39894] Re: faster Enumerator#each by rb_block_call with current block
— Yukihiro Matsumoto <matz@...>
2009/12/19
まつもと ゆきひろです
[#39897] Re: faster Enumerator#each by rb_block_call with current block
— Yusuke ENDOH <mame@...>
2009/12/20
遠藤です。
[#39912] [Bug #2522] Segmentation Fault is occurred on r26158 by running rubyspec — Kenta Murata <redmine@...>
Bug #2522: Segmentation Fault is occurred on r26158 by running rubyspec
4 messages
2009/12/23
[ruby-dev:39821] Re: RbConfig.rubybin
From:
KOSAKI Motohiro <kosaki.motohiro@...>
Date:
2009-12-01 01:37:49 UTC
List:
ruby-dev #39821
> 須藤です。 > > In <20091130192237.5C02.A69D9226@jp.fujitsu.com> > "[ruby-dev:39815] Re: RbConfig.rubybin" on Mon, 30 Nov 2009 19:28:39 +0900, > KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote: > > >> > ただ、メソッド名はRbConfig.rubyの方がよい気がします。 > >> > >> ちょっとチャレンジな気がしますが、それもいいかも知れませんねぇ。 > >> > >> そうするとすると、こうでしょうか。 > > > > 反対に投票します。 > > "ruby" の4文字からパス名だと類推できる気がしないからです。 > > > > そもそも、4文字にまで縮めないといけないほど頻繁に使われるものか疑問です。 > > 私がrubybinよりrubyの方がよいと思うのは、よく使うから短くした > いという理由ではなくて、rubyとbinがくっついていたり、binはバ > イナリの略?とかという理由でrubybinがわかりづらかったからで > す。 ああ、なるほど。これはなっとく。 binがexecutableの略というのは、OSを超えて通用する一般的な文化ではない気がします。 > > ruby_pathとかであれば、それでもよいと思っています。 > > > 蛇足ですが、パス名を表す名前としてコマンドと同じ名前を使うの > は、よくあるパターンだと思っていました。Rubyのconfigureで > も--with-baserubyというオプションがありますが、 > > --with-baseruby=RUBY use RUBY as baseruby; RUBY is the pathname of ruby > > というように、コマンドのパス名の変数名としてRUBYを使っていま > す。 > > > > ruby_interpreter_path_super_galactica_magnum とかやたら長い名前だとしても、 > > APIリファレンス一発で引けるなら誰もこまらないような。 > > 名前を考えることは諦めない方がよいと思うのですが。。。 ちょっと、脱線して、ここにつなげさせてもらおう。えーと、意図としては 名前を考えるのを諦めようといっているのではなく逆でした。 僕の中ではメソッド名の善し悪しの判断基準が、ワンライナーで使われるような ものと、ライブラリで使われるようなものが違います。 ワンライナーだと元が5分作業なので、リファレンスマニュアル調べる時間で +5分されてしまうと生産性が二倍悪化。なので、覚えやすいメソッド名が善。 ライブラリ観点でいうと、もともとが1日作業なので+5分は誤差、に加えて 後から何回もコードを読む羽目になるので、省略名のメソッドとかは将来の 自分を困らせるので悪。 で、Rubyコマンドのパスをワンライナーから知りたいケースがあるかと 考えた時に「いや、そんなのが頻繁に必要なら言語仕様にもっと重大な欠陥があるだろ」 と思ったので、長い説明的な名前のほうが生産性あがる気がするぜ、的な 事を書きました。 # なお、本件についてはすでに結論が出ているので、再反論という意図ではありません。 # 念のため。