青木です。

  In mail "[ruby-list:39325] File.fnmatch  の改良について"
    H.Yamamoto <ocean / m2.ccsnet.ne.jp> wrote:

> はじめまして、山本です。

> 仕様は次のとおりです。

それで結局、1.6.8 あるいは 1.8.1 から動作が変わるのは
どこなんでしょうか。それが示されないと長短の判断のしようが
ありません。できればユニットテストを用意して、これとこれと
このテストケースが失敗するようになります、しかし次のような
利点があります……。と言ってくれればベストです。

あと、そもそもなぜ fnmatch を改良しようと思ったのでしょうか。
改良しなければならない理由はなんなんですか。わたしが ruby-dev
も含めて見た限り、まず fnmatch の実装を高速化することが第一義
で、残りはその実装の過程で都合のいいように仕様を改変したように
しか見えません。そして、だからこそわけのわからない主張になるし、
他の人も意見の言いようがないのではないでしょうか。

そもそも「改良」というからには悪いところを直すのでなければ
なりません。ならば、まずどこがどのように悪いのかを指摘すべきです。


以上を踏まえて個人的にまとめなおしてみました。
意図と違うところがあれば遠慮なく御指摘ください。

= File.fnmatch の仕様の問題点

  * fnmatch というメソッド名からするとユーザはシェルのグロブと
    同じ動作を想像すると思われる。しかし実は fnmatch は
    ただのパターンマッチャで、File::FNM_PATHNAME フラグを
    渡さないとグロブのような動作をしない。具体的には、「/」が
    特別扱いされず、「*」や「?」にマッチしてしまう。
    これは不便である。

    (青木註: もちろん反論はできる。fnmatch という名前から
     fnmatch(3) を想像し、それと同じ動作を期待する人も
     いるだろう。つまり論点は、fnmatch という名前から C の
     fnmatch(3) を期待する人としない人の比率がどのくらいで
     あるか、とまとめられる)

  * Dir.glob には「**」があるのに fnmatch には「**」がない。
    これは一貫性に欠ける。

  * SUSv3 準拠でない (?)

= 解決案

  * デフォルトを File::FNM_PATHNAME の動作にする。動作を
    元に戻したい (「/」を「*」や「?」にマッチさせたい) 場合
    には、新しいフラグ FNM_SEPMATCH を指定させる。

  * File.fnmatch にも Dir.glob と同じ内部ルーチンを採用し、
    「**」を実装する。

= 問題

  * File.fnmatch の互換性がなくなる。

  * 定数 File::FNM_PATHNAME を参照していると互換性がなくなる。
    (青木註: 実装を考えると、FNM_PATHNAME をなくす必要はない。
     FNM_PATHNAME を 0 と定義すればこの点での互換性は保てるはずである)



それはそれとしてわたしの意見を言うと、FNM_PATHNAME をデフォルトに
するのには反対です。対案としては、例えばパス専用の新しいメソッドを
作って、そちらで FNM_PATHNAME をデフォルトにするのはどうでしょうか。
-------------------------------------------------------------------
青木峰郎