[ruby-dev:38214] Re: big time

Tanaka Akira さんは書きました:
> In article <[e-mail]>,
>   Urabe Shyouhei <[e-mail]> writes:
> 
>> このパッチが具体的にどうという話ではなく、もうちょっと一般的な方針として、どう
>> かなあという気がしています。不正な値が見つかるのは早ければ早い程よいと思うから
>> です。
> 
> それだけであれば、よい話だと思います。
> 
>> たとえば、touch(1)のクローンを作っていたとしましょう。んで、コマンドライン引数
>> の解釈にバグがあって、紀元前3億世紀とか、なんでもいいですけど、ともかくファイル
>> 更新時刻として不正なTimeオブジェクトを作ってしまったとしますね。そうすると、
>>
>> 1) 見つけたいバグがあるところ:
>>    コマンドライン引数解釈器
>> 2) 実際に例外が上がるところ:
>>    File.utimeとか
>>
>> という不一致が生じてしまうわけです。ここで、2)のほうもあなた自身が書いたコード
>> ならまだ追いかけられるかもしれませんが、えてして2)はライブラリの中だったりとか
>> するわけですよ。具体的にはFileUtilsとか。そうすると
>>
>> * スクリプト作者はどこが悪いのか追いかけられない
>> * ライブラリ作者は自分のせいじゃないバグ報告でモチベーションが削がれる
>>   (だってユーザーが見るのは2のほうのバックトレースだし)
>>
>> という問題がある。これはよくないと思います。
> 
> Time が File.utime のために存在する、あるいはそこまでいかな
> くても大半の場合 File.utime で使われる、というなら、
> File.utime の都合に Time をあわせることにはあり得る話だと思
> います。そうすれば、たしかにその問題を早期に発見することがで
> きます。
> 
> しかし、実状としてはそうは思いません。Time オブジェクトの主
> 要な用途が File.utime かというと、そうではないように思います。
> 表示したり、比較したりといった time_t の制約が問題にならない
> 用途がむしろ主要な用途であるように思います。
> 
> そして、File.utime 以外に time_t な制限があるものがあるかと
> いうと、実はないのではないかと思います。探したんですが、見つ
> かりませんでした。あったら教えてください。

コアの中だけで見るとなさそうですね。拡張ライブラリまで見ると
Zlib::GzipWriter#mtime=とか、まあなんかありそうです。あと他のプロセスと通信する
場合にtime_tを吐く必要がある例は思い浮かびますが、さすがにそれはちょっと別の話
かな。

> というわけで、File.utime に使うときに問題を早期に発見できる
> という利点と、メールの Date: フィールドとかから読み込んだ時
> 刻を Time 経由で比較できるなどといった利点とを比べて、どちら
> を選ぶか、という話になります。
> 
> ここで後者を選ぶのはどうでしょうか、というのがこの提案という
> ことになります。
> 
> 卜部さんの指摘は一般的な話ということなので、これを一般化する
> と、利点も欠点もあるけれど、個々の用途に応じて全体としてどち
> らが便利なのかを考えて選ぶのが良いんじゃないでしょうか。
> 
>> こういう話はべつにTimeに限った話じゃなくて、最近見かけた例としては1.9でERBに与
>> えるテンプレートと埋め込む文字列のencodingがcompatibleでない場合などは、同様に
>> ERBの中から例外が上がってくるんだけど、一体どのオブジェクトがいけなかったのかが
>> さっぱり分からん。とか、まあ、いろいろありそうな話じゃないですか。一般的に。
> 
> はい。いろいろあるでしょう。個々の状況を具体的に検討して考え
> ていくしかないと思います。

個別の状況を具体的に検討しなきゃいけない場合ってのはえてして何かの仕組みが足り
てないときな気がしますが...

>> これまではTimeは「生成できれば、とりあえずOSとのやりとりには使える」という、逆
>> に言えばまずい時には生成する瞬間に例外になってくれていたわけで、これはよいイン
>> ターフェースだったと思うわけです。今回そのような特徴を排することになると、より
>> デバッグが難しい方向に倒れてしまう気がします。どんなもんでしょう。
> 
> Time に関しては、File.utime は主要な用途ではなく、その問題よ
> りも利点が大きいであろう、というのが私の判断です。
> 
> ただ、一般に、複数の利点をすべて得る方法を考えるのは重要だと
> 思います。たとえ無理という結論になるとしても、すくなくとも考
> えるべきです。
> 
> この件についてあまりうまい方法を思いつくわけじゃないんですが、
> とりあえず time_t の範囲内かどうか検査するメソッドをつけると
> いうのはあるかもしれません。あとは生成時に time_t の範囲外を
> 受け付けないメソッドとか?
> 
> 本質的には、Time オブジェクト生成の時点で File.utime にたど
> り着くかどうかを自動的に判断できればいいのでしょうが、これが
> 現実的にできるかというと、ちょっとわかりません。

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

今回の場合で言うと、time_tはTimeが表現できる時刻たちの真部分集合になっているわ
けで、OOP的にはTimeのサブクラスとしてtime_tなクラスを表現するのが一番自然だとは
思います。File.utimeはtime_tのほうしか受け付けないことにして、ダウンキャストは
明示的にやらせることにすれば、ダウンキャストのタイミングで警告を出したり例外に
したりするのは、変数を追跡するよりは大分簡単だと想像します。

それがRubyっぽいかは、ちょっとなんとも分かりかねますが。