In article <87k778qq7g.wl / tempest.nemui.org>,
  Tatsuki Sugiura <sugi / nemui.org> writes:

> パス名そのものの操作(dirname,Pathname#cleanpath...etc)は、File, Dir
> の両方のクラスで同じように出来れば良いのではないでしょうか。

いや、作った後ではなく、作る時に困るのではないかということです。

> # と言ってもまだ実装してませんが……
>
> 結局パス名が指す実体への操作(open, entries...etc) をするときには、調べ
> ないといけないわけで、余り手間は変わらない気がします。

どうなんでしょうね。私は調べなくてもいいケースも多々あるように思います
が。また、実体が無いとか、ディレクトリを指しているシンボリックリンクと
か、判断に困る例がいろいろありそうな気がします。

> クラスが "パス名" ならその方が良いと思いますが、明示的に "ディレクトリ"
> だと指定してインスタンスを作ったなら、そこから更に entries を呼ば
> ないといけないのは面倒に思います。

ディレクトリの中身を表現しているオブジェクトなら、そのほうが良いと思い
ます。しかし、そのオブジェクトがディレクトリのパス名も同時に表現してい
るというのはあまりうまい切り分けかただとは思いません。

> 元々、組み込み Dir を使っていて、「openが面倒」「IO みたいなものが
> 帰ってくるのが面倒」と言うのがあったので、 Dir#[](aFixnum),
> Dir#grep, Dir#map 等は出来るようにしたいです。

私はそもそも Dir.open はあまり使いませんね。どちらかというと、
Dir.entries や Dir.foreach を使います。

Dir に関して私が感じる面倒さは、. と .. を取り除くのとか、ディレクトリ
のパス名を連結するあたりかな。
(だから Pathname#children を作ったのですが)

> あとはエントリ数が膨大な場合は、配列を作って返すよりも、Dir.each
> を呼ぶと、裏側で順次 IO から読んでエントリを返してくれる方がメモリー
> 消費等の点で嬉しい──
>
> ──かと思っていたんですが、今試してみるとメモリ消費は全然大したこと
> ありませんね。
> # それにローカルファイル以外だと結局エントリのキャッシュを持つ事に
> # なるでしょうし。
>
> エントリの後の方の要素を一気に取り出す際、そのまま配列の様に
> Dir.new("/dir")[10000]
> とか出来るなら、多少効率を上げられるかもしれませんが……

どうでしょうねぇ。エントリ数が膨大な場合には、どちらかというと stat の
コストが気になります。上記の話はたぶん stat せずに文字列としてのファイ
ル名を生成している場合だと思うのですが、File.new するか Dir.new するか
を判断するために一気に全部 stat すると実行コストの点で不幸なことになり
そうに思います。それをどうにかするためには、要素を lazy に生成するとい
う手がありますから、それが可能なように Array ではないもので扱う、とい
うのはひとつのやりかたかも知れません。

もちろん私としては、Pathname のように stat 無しで生成できるものにして
おけばそんなコストは気にしなくて済むのに、と思うわけですが。
-- 
[田中 哲][たなか あきら][Tanaka Akira]