[#39325] File.fnmatch の改良について — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>

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

18 messages 2004/03/05

[#39429] trial version of Ruby/Tk — Hidetoshi NAGAI <nagai@...>

永井@知能.九工大です.

18 messages 2004/03/23
[#39454] Re: trial version of Ruby/Tk — "Shirai,Kaoru" <shirai@...> 2004/03/31

白井です。

[#39460] Re: trial version of Ruby/Tk — Hidetoshi NAGAI <nagai@...> 2004/04/01

永井@知能.九工大です.

[#39465] Re: trial version of Ruby/Tk — "Shirai,Kaoru" <shirai@...> 2004/04/01

白井です。

[#39466] Re: trial version of Ruby/Tk — Hidetoshi NAGAI <nagai@...> 2004/04/01

永井@知能.九工大です.

[#39453] Re: int/int in Ruby2? — Masaaki Sakano <mas@...>

坂野 正明です。

36 messages 2004/03/31
[#39455] Re: int/int in Ruby2? — NISHIMATSU Takeshi <t-nissie@...> 2004/03/31

西松と申します.

[#39470] Re: int/int in Ruby2? — Masaaki Sakano <mas@...> 2004/04/01

坂野 正明です。

[#39473] Re: int/int in Ruby2? — matz@... (Yukihiro Matsumoto) 2004/04/01

まつもと ゆきひろです

[#39484] Re: int/int in Ruby2? — Masaaki Sakano <mas@...> 2004/04/03

坂野 正明です。

[#39528] Re: int/int in Ruby2? — "T Akutsu" <locrian@...> 2004/04/09

あくつです。なんかわくわくしてきだぞ。(^^;)

[ruby-list:39327] Re: File.fnmatch の改良について

From: Minero Aoki <aamine@...>
Date: 2004-03-05 10:17:19 UTC
List: ruby-list #39327
青木です。

  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 をデフォルトにするのはどうでしょうか。
-------------------------------------------------------------------
青木峰郎

In This Thread