まつもと ゆきひろです
In message "[ruby-ext:01598] Re: require 'dir/...'?"
on 01/03/02, Minero Aoki <aamine / dp.u-netsurf.ne.jp> writes:
|とりあえず前提として、ぼくが推すのは require 'foo' で
|foo.rb → foo.so → foo/* のロードです。そのうえで、
|> 私だけかもしれませんが、始めひとつのファイルで十分だった foo.rb が
|> いつの間にか膨張して foo/ を作って分割ということがわりとあるので。
|> そういう場合にもエントリーポイントを変えずに済むというのがa案(
|> 「foo.rb foo/方式」)の利点のひとつだと思います。
|
|というような場合(よくありそうだと思われる)には一致するでしょう。もとも
|と論理的にまとまりがあるファイル群をディレクトリにまとめちゃおう、とい
|うのが発端だったわけですから、その逆に、同じディレクトリに入ってるもの
|はまとまりのあるものだ、と(デフォルトで)みなしても問題は少ないと思うん
|です。
えーと、私もそれには同意します。が、「まとまり」があるのと
「一緒にロードする必要がある/ロードするのが当然」とは違うよ
うに思います。例が出ているのでは foo/debug.rb というのがあり
ます。そういうファイルが「たまたま」ひとつ欲しいと思っただけ
で
|デフォルトと違う場合はどうするかというと、webrick 方式(と仮に呼びます)
|に webrick.rb を明示的に作って制限すればいい。
のように「デフォルトと違う」と呼ばれてしまうのは心外なのです。
|一方 2. は、全部ロードされたら困る場合と困らない場合がある。困る
|のはどういう場合かというと、(jcode.rb みたく)ロードされたら動作が
|変わってしまうものがある場合です。
他にもライブラリ中のいくつかのファイルが同時にロードされるこ
とを想定していない(条件ロード用のような)ケースもありえますね。
一方、あおきさんの推す require 'foo' で foo/* もロードすると
いう「改造」を行ったとして、嬉しいのは
* foo.rb と foo ディレクトリが両立しないのが嬉しい(気分)
* 全部同時にロードしても問題がないように設計したライブラリ
の作者がユーザの界面であるfoo.rbやfoo/all.rbのようなファ
イルの更新をサボれる(ちょっと楽)
の2点だけのような気がします。これ(特に後者)が成立する確率は
かなり低いように思います。人によって違うでしょうが。
私の判断基準からいうと
* 「foo.rbとfoo/の両立がイヤ」という気分を満足させるための
改造には納得できない
* しかも、ユーザにどんな機能をどのように提供するかどうかは
ライブラリの要であり、その部分で怠けること(また怠けるこ
とを支援する機能を追加すること)は推奨できない
* まして、その改造により(これまた納得していない)「ライブラ
リはfoo/*という形式でロードできて当然(そうでないファイル
はサブディレクトリに格納せよ)」という暗黙の圧力を与える
結果になるのでは、ますます承服できない
ので、require 'foo' で foo/* をロードするようにはしないと思
います。たとえば、あおきさんのようなやり方を望む人は
dirname = File.dirname(__FILE__)
Dir.glob(dirname+"/*.rb").each{|r| require r}
という foo/all.rb のようなものを用意すれば良いのだろうと思い
ます。で、その名前はおそらく foo/all.rb であるべきなのだと思
います。ある機能を提供したいんじゃなくてライブラリの機能を
「全部」提供したいんでしょうから。
ライブラリがある機能を提供したいんであれば、そのライブラリの
名前はその機能を体現した名前であるべきでしょう。たとえば
tmailならtmailという機能が欲しいわけで、それがサブディレクト
リに入っているかどうかには関心がないです。それがnetというく
くりに分類されているからnet/httpとする場合には、その名前が
「netに分類されるhttp機能」ということを体現しているはずです。
しかし、tmail/tmailはtmailだけに比べて「分類のための分類」し
か導入していないように感じられます。一方、tmail/all は「(い
くつのある程度独立した)tmailに含まれる機能全部を取り込む」と
いう意味と意思が感じられます。
まつもと ゆきひろ /:|)