[ruby-dev:38274] Re: big time

In article <[e-mail]>,
  Urabe Shyouhei <[e-mail]> writes:

> なるほど。検査メソッドという表現から述語メソッドを想像していましたが、例外を発
> 生するメソッドであればありかもしれないと思います。

あとからもうひとつの可能性を考えつきました。

もしかして、卜部さんが想定する TypeError というのは、
File.utime が発生するものだったりしませんか?

File.utime が発生する例外については、サブクラスを作らなくて
も「時刻が time_t の範囲外である」というメッセージで例外を発
生するのは簡単だし、そうすべきだと思います。

> 利点がないんでしょうか。ライブラリ作者が責任範囲を明確にできるのは利点ではない
> ですかね。それがアプリケーション開発者の不幸に繋がるかは分かりませんが。

どう明確になるんでしょう?

File.utime に渡す時刻を引数に指定するのがアプリケーションの
責任なら、それはそれで明確ではないですか?

それに失敗したら time_t の範囲外という例外が出るわけですし。

> utimeの直後にfstatで確認するとか。いやもちろん競合状態でうまくいかないのは理解
> できますので、難しそうかなとは思いますが。

GNU/Linux で VFAT なファイルシステムを mount して
あるファイルを 1970-01-01 に File.utime すると、失敗しないし、
stat すると設定できたように見えるんだけど、マウントし直すと
1980-01-01 になっているという現象を見つけてしまいました。

stat しても実際になにが起きているのかはわからないようです。

> [ruby-dev:38202] のケースを救いたいです。

読み直してみました。

touch クローンであれば、コマンドライン引数解釈器が生成した
Time オブジェクトがそのまま File.utime までたどりつくでしょ
うから、File.utime が「time_t の範囲外である」というメッセー
ジで失敗すれば、Time オブジェクトを生成した、touch クローン
の作者が問題を見つけるのは別に難しくないのではないでしょうか。

ライブラリ側からから見ると、アプリケーションから渡された
Time オブジェクトをそのまま File.utime に渡している限り、そ
のエラーメッセージは外部の問題であることを明らかに示している
のでその旨を述べてバグレポートを却下すればいいのではないでしょ
うか。

>> その解決による利点は、互換性を損なうことを含む欠点よりも大き
>> なものですか?
>
> 前から理解できないので言及してこなかったわけですが、その大きさってのはどうやっ
> て定量的に評価するんですか?大きさを比較するには量的な評価ができないことには不可
> 能だと思います。

File.utime が Time オブジェクトを受け付けなくなると、
いままで File.utime に Time を渡していたすべてのコードで問題
が起きます。

それに対して、File.utime が、time_t の範囲外の Time オブジェ
クトを受け付けないというのは、すべてよりは少ないコードでしか
問題が起きないでしょう。

卜部さんが救いたいというのは後者に関する話ですが、それは前者
の問題よりは少ないでしょう。

また、File.utime がなんらかの範囲外でうまく動かないという意
味で、似た問題は 64bit time_t で NFSv3 とか GNU/Linux で
VFAT とか既にあるので、そこからの類推も可能です。ML の過去の
メールを検索しても範囲外の問題と明確にわかるものはありません
でした。これから類推すると問題は例外的な話におさまるでしょう。

あと、前から、ということなので、Time を拡大する利点と
それによる File.utime に対する欠点の比較についても触れておき
ます。

利点のほうが大きいと私が考えるのは、Time を使うケースと
File.utime を使うケースで前者がずっと多いという経験から来て
います。

このことは、Google Code Seach で検索すると
* lang:ruby Time が約230,000件
* lang:ruby File.utime が 924件
という数になることからも裏付けられます。Time 検索結果がすべ
て Time クラスを指しているわけではないでしょうが、これだけの
差があれば、Time クラスがずいぶんと多いのは確かでしょう。
(実際、検索結果を眺めると、1/100 よりはずいぶんと大きな割合
で Time クラスを使うコードがヒットしています)

従って、ある変更によって、File.utime に使うときの欠点とそれ
以外での利点が両方あった場合、実際に使う回数を考えると、利点
のほうがずっと多くなることが推測できます。
-- 
[田中 哲][たなか あきら][Tanaka Akira]