From: Urabe Shyouhei Date: 2009-04-02T01:37:02+09:00 Subject: [ruby-dev:38245] Re: big time 卜部です。 Tanaka Akira さんは書きました: > In article <49D33295.3000600@ruby-lang.org>, > Urabe Shyouhei writes: > >> うーん、もともとの >> 「ライブラリ作者がいわれのないバグ報告で疲弊するのを避けたい」 >> というニーズはあまり満たしてくれないのが気になりますが、しょうがないのかなあ。 > > サブクラスにすると満たされるんですか? 少なくともTypeErrorのメッセージには"(expected なんとか)"とか本来の意図が表示さ れてますからね。ライブラリ作者の意図は表現できます。 >> そういう場合は両方を包含するようなスーパークラスを定義するのだと思います。たと >> えばFloatとBignumには共通のNumericというスーパークラスがあります。 > > メソッドで検査するなら、検査したい範囲それぞれについてひとつ > 定義すればいいのに対し、クラスで行うと検査したい範囲それぞれ > についてひとつ定義するのに加えて、そういうスーパークラスを定 > 義することになります。そのスーパークラスを定義することによっ > てどんな利点が得られますか? メソッドよりも便利ですか? ?「〜定義することになります」のくだりがよく理解できてません。 time_t < Time gzipのmtime < Time では何が問題なんでしょう? >> たとえば3/2のクラスはなんでしょうか? Fixnumですよね。 >> Rubyの場合は「四則演算では型は変えない方に倒す」という設計なのだと思います。 > > そういう設計だとは思いません。 > > たとえば 65536 * 65536 は Bignum ですね。 それは(前のメールで田中さんが自ら書かれたとおり)安全だから、なんじゃないですか。 >> べつに静的型を導入しなくてもFile.utimeより前に例外を起こす方法はあるじゃないで >> すか。つまり現状はそうなわけですけど。 > > そうですね。そのかわり、2038年などという制約を File.utime に > 関係ないところにまで強制するわけです。 > > 私は、問題が存在するにせよ、問題よりも利点のほうが大きいと主 > 張しているのですが、卜部さんは問題のほうが利点よりも大きいと > 考えますか? それに対する現在のお返事は「File.utimeだけ隔離すればよい」ですが。 utimeを隔離してもまだ2038年の制約が他の部分に及びますか? >> そもそもなんでFile.utimeにはTimeオブジェクトを渡さないといけないんですか? >> File.utimeの引数に渡すオブジェクトが、比較したり表示したりするTimeオブジェクト >> でないといけない理由はないと思うんですけど。 >> File.utimeがそんなに特殊ならTimeと切り離せばいいんじゃない? > > わたしはそうしたいとは思いません。 > 卜部さんはそうしたいんですか? わりといい考えだと思ってますけど。 >> それはCのうれしくなさがRubyのレベルまで上がってきてるだけで何の解決にもなってな >> いように思えます。 > > Time の範囲を拡大するにあたって、それを解決しないといけない > んですか? 「たとえ無理という結論になるとしても、すくなくとも考えるべきです。」という風に 仰ったのは田中さんですよね? ------- ちょっと発散しかかってる気がするので現時点での卜部の意見をまとめておきますが、 * File.utimeがどうにかなるのであればTimeの範囲が拡大されるのはかまわない * そんなにFile.utimeだけ別の振る舞いをするなら、File.utimeの引数にはTimeではな いオブジェクトを受け付けるべき。 です。なにがなんでもTimeはtime_tであるべき、とかは思っていません。