From: Urabe Shyouhei <shyouhei@...>
Date: 2009-04-03T20:58:30+09:00
Subject: [ruby-dev:38271] Re: big time

Tanaka Akira さんは書きました:
> In article <49D39822.6070505@ruby-lang.org>,
>   Urabe Shyouhei <shyouhei@ruby-lang.org> writes:
> 
>> 少なくともTypeErrorのメッセージには"(expected なんとか)"とか本来の意図が表示さ
>> れてますからね。ライブラリ作者の意図は表現できます。
> 
> 検査メソッドでは出来ないんですか?
> 
> つまり、
>   subclass_time = time.convert_to_the_subclass_for_time_t
> というように変換メソッドを呼ぶのと、
>   time.check_this_is_in_the_range_of_time_t
> というように範囲検査メソッドを呼ぶのとで、どちらも例外が起き
> るとすれば、そのメッセージに「時刻が time_t の範囲外である」
> と記述するのはどちらも同様に可能でしょう。
> 
> それは「time_t の範囲内の値を指定せよ」という本来の意図を示
> していると思います。

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

調べ方が下手なせいかちょっとそのようなメソッドの例を他に思い浮かばないので、
Rubyっぽさがどうなのかは何とも分かりませんが。

>>>> そういう場合は両方を包含するようなスーパークラスを定義するのだと思います。たと
>>>> えばFloatとBignumには共通のNumericというスーパークラスがあります。
>>> メソッドで検査するなら、検査したい範囲それぞれについてひとつ
>>> 定義すればいいのに対し、クラスで行うと検査したい範囲それぞれ
>>> についてひとつ定義するのに加えて、そういうスーパークラスを定
>>> 義することになります。そのスーパークラスを定義することによっ
>>> てどんな利点が得られますか? メソッドよりも便利ですか?
>> ?「〜定義することになります」のくだりがよく理解できてません。
>> time_t < Time
>> gzipのmtime < Time
>> では何が問題なんでしょう?
> 
> 「そういう場合は両方を包含するようなスーパークラスを定義する
> のだと思います」という記述から、time_t と gzip の mtime を包
> 含するスーパークラスを定義するのだと思っていました。
> 
> 定義しないんですか?

time_tとgzipのmtimeを包含するスーパークラスとして田中さんのパッチのTimeで不十分
な例が思い浮かばないという話です。

>> それは(前のメールで田中さんが自ら書かれたとおり)安全だから、なんじゃないですか。
> 
> 私がこのスレッドで安全と書いたところは見つけられませんでした。
> 
> 私の書いたどの記述を指していますか?


[ruby-dev:38227] の
> 失敗しない場合、Bignum と Fixnum のように、包含関係であれば
> クラスを選ぶのに悩まなくて済むかもしれませんが、

の部分を指していたつもりでした。安全とは言ってないですね。ごめんなさい。

>> それに対する現在のお返事は「File.utimeだけ隔離すればよい」ですが。
>> utimeを隔離してもまだ2038年の制約が他の部分に及びますか?
> 
> 隔離というのが File.utime が Time オブジェクトを受け付けなく
> するという意味なら、それは利点のない非互換性であり、ユーザが
> 不幸になると感じます。

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

>> 「たとえ無理という結論になるとしても、すくなくとも考えるべきです。」という風に
>> 仰ったのは田中さんですよね?
> 
> はい。無理っぽいと思います。可能だと思いますか?
> 
> 実はいくつか試したんですが、utime システムコールを呼んでも、
> うまくいったかわからない感じですね。

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

>> * そんなにFile.utimeだけ別の振る舞いをするなら、File.utimeの引数にはTimeではな
>> いオブジェクトを受け付けるべき。
> 
> 確認ですが、これは File.utime は Time を受け付けるべきでない、
> という意味ですね?

はい。

> Time を受け付けつつ、Time でないものも受け付けるという意味で
> はないですね? ちなみに、現在でも、File.utime は Time でない
> オブジェクトとして整数を受け付けます。

整数も受け付けるべきでないと思います。

> 私は、File.utime が Time を受け付けなくするのは反対です。
> 少なくとも互換性を損なうという問題があります。
> 
> 卜部さんは、なぜそうしたいんですか?
> 
> 「File.utime が Time を受け付けない」ことによってどんな問題
> を解決したいんでしょうか?

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

> その解決による利点は、互換性を損なうことを含む欠点よりも大き
> なものですか?

前から理解できないので言及してこなかったわけですが、その大きさってのはどうやっ
て定量的に評価するんですか?大きさを比較するには量的な評価ができないことには不可
能だと思います。