From: Tanaka Akira Date: 2009-04-03T13:14:09+09:00 Subject: [ruby-dev:38267] Re: big time In article <49D39822.6070505@ruby-lang.org>, Urabe Shyouhei 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 の範囲内の値を指定せよ」という本来の意図を示 していると思います。 >>> そういう場合は両方を包含するようなスーパークラスを定義するのだと思います。たと >>> えばFloatとBignumには共通のNumericというスーパークラスがあります。 >> >> メソッドで検査するなら、検査したい範囲それぞれについてひとつ >> 定義すればいいのに対し、クラスで行うと検査したい範囲それぞれ >> についてひとつ定義するのに加えて、そういうスーパークラスを定 >> 義することになります。そのスーパークラスを定義することによっ >> てどんな利点が得られますか? メソッドよりも便利ですか? > > ?「〜定義することになります」のくだりがよく理解できてません。 > time_t < Time > gzipのmtime < Time > では何が問題なんでしょう? 「そういう場合は両方を包含するようなスーパークラスを定義する のだと思います」という記述から、time_t と gzip の mtime を包 含するスーパークラスを定義するのだと思っていました。 定義しないんですか? > それは(前のメールで田中さんが自ら書かれたとおり)安全だから、なんじゃないですか。 私がこのスレッドで安全と書いたところは見つけられませんでした。 私の書いたどの記述を指していますか? > それに対する現在のお返事は「File.utimeだけ隔離すればよい」ですが。 > utimeを隔離してもまだ2038年の制約が他の部分に及びますか? 隔離というのが File.utime が Time オブジェクトを受け付けなく するという意味なら、それは利点のない非互換性であり、ユーザが 不幸になると感じます。 > 「たとえ無理という結論になるとしても、すくなくとも考えるべきです。」という風に > 仰ったのは田中さんですよね? はい。無理っぽいと思います。可能だと思いますか? 実はいくつか試したんですが、utime システムコールを呼んでも、 うまくいったかわからない感じですね。 > ちょっと発散しかかってる気がするので現時点での卜部の意見をまとめておきますが、 静的型など、短期的にはどうにもならない話題を出してしまったの は反省しています。 > * そんなにFile.utimeだけ別の振る舞いをするなら、File.utimeの引数にはTimeではな > いオブジェクトを受け付けるべき。 確認ですが、これは File.utime は Time を受け付けるべきでない、 という意味ですね? Time を受け付けつつ、Time でないものも受け付けるという意味で はないですね? ちなみに、現在でも、File.utime は Time でない オブジェクトとして整数を受け付けます。 私は、File.utime が Time を受け付けなくするのは反対です。 少なくとも互換性を損なうという問題があります。 卜部さんは、なぜそうしたいんですか? 「File.utime が Time を受け付けない」ことによってどんな問題 を解決したいんでしょうか? その解決による利点は、互換性を損なうことを含む欠点よりも大き なものですか? -- [田中 哲][たなか あきら][Tanaka Akira]