[ruby-dev:38216] Re: big time

卜部です。

Tanaka Akira さんは書きました:
> In article <[e-mail]>,
>   Urabe Shyouhei <[e-mail]> writes:
> 
>> コアの中だけで見るとなさそうですね。拡張ライブラリまで見ると
>> Zlib::GzipWriter#mtime=とか、まあなんかありそうです。あと他のプロセスと通信する
>> 場合にtime_tを吐く必要がある例は思い浮かびますが、さすがにそれはちょっと別の話
>> かな。
> 
> ふむ。これは違うんじゃないですか?
> 
> Zlib::GzipWriter#mtime= は gzip フォーマットの mtime を指定
> するもので、RFC 1952 によると MTIME フィールドは 4byte です
> から、これは OS の time_t のサイズによらず、32bit なんじゃな
> いですか?
> 
> つまり、32bit time_t な OS では一致しますが、64bit time_t な
> OS では一致しないんじゃないでしょうか。

すると現状ひょっとしてバグってますか?

zsh % ruby -rzlib -e'

Zlib::GzipWriter.open("/dev/null") {|gz|
   gz.mtime = Time.at(1<<32 - 1)
}'
ruby 1.9.2dev (2009-03-11 trunk 22881) [x86_64-linux]
-e:2:in `mtime=': integer 2147483648 too big to convert to `int' (RangeError)
        from -e:2:in `block in <main>'
        from -e:2:in `open'
        from -e:2:in `<main>'
zsh: exit 1     ruby -rzlib

# だんだん話がずれてきたな

>> 個別の状況を具体的に検討しなきゃいけない場合ってのはえてして何かの仕組みが足り
>> てないときな気がしますが...
> 
> 私の見方としては、この問題は用法に依存します。
> 
> time_t として使う用法が全てなのか、大半なのか、稀なのか、と
> いうことです。
> 
> そういう用法は外部で決まるので、Time クラス自体をいくら眺め
> てもわからず、具体的に検討しなければならないのは自然だと思い
> ます。
> 
> ただ、用法に依存するような仕様はそもそもよろしくない、という
> ことならそれはそれで傾聴に値する意見だと思います。
> 
> もしそうだとすると、time_t という用法に依存した仕様はよくな
> くて、Time は時刻というものの性質自体に自然に対応するように
> すべきで、少なくとも 2038年で途切れるというのはなんとも不自
> 然、ということになる気がしますが。

むしろtime_tの用法を包含した仕様にすべきで、切り捨てるべきではない、という(そこ
まで強くは言いませんが)意図でした。time_tを切り捨てない方策としてサブクラス化を
提案したつもりです。実現性はともかく。

>> 風呂敷を広げると、例外ってロジックの誤りを処理するのには向いているけども、不正
>> な値を追跡するのには向いてないと思います。他の言語でそういうのをどう処理してる
>> かというと、型で頑張っているんじゃないかなあ。HaskellだとData.Time.UTCTimeの他
>> にSystem.Posix.Types.EpochTimeとかいう型があって、相互の変換は明示的に行わない
>> といけなそうな感じになってます(試してないけど)。
> 
> そうですね。型で値を制約すれば、制約に反したところで発見でき
> ます。

それ以外の場合にも興味があります。型がない他の言語では不正な値がどこからやって
きたかをどのようにデバッグするんでしょう。だれか知りませんかね。

>> 今回の場合で言うと、time_tはTimeが表現できる時刻たちの真部分集合になっているわ
>> けで、OOP的にはTimeのサブクラスとしてtime_tなクラスを表現するのが一番自然だとは
>> 思います。File.utimeはtime_tのほうしか受け付けないことにして、ダウンキャストは
>> 明示的にやらせることにすれば、ダウンキャストのタイミングで警告を出したり例外に
>> したりするのは、変数を追跡するよりは大分簡単だと想像します。
> 
> まずは引数に型宣言をつけないといけませんね。
> あるいは型推論に挑戦するか。
> 
> それを実現した後なら、ダウンキャストを忘れたら File.utime に
> たどり着く前に検出できるでしょう。
> 
> ところで gzip の mtime の値を表現するクラスも、time_t 用のク
> ラスとは別に作るんでしょうか。

BignumとFixnumの例がありますので、time_tよりもさらに小さいクラスがあっても驚き
ません。

>> それがRubyっぽいかは、ちょっとなんとも分かりかねますが。
> 
> かなりあきらかに Ruby っぽくないというレベルに達していると思
> います。

そうかなあ。デバッグしやすいプログラムが書けるのは(特にPerlと比べた)Rubyの大き
な特徴の一つだと思うんだけどなあ。