卜部です。

take_tk wrote:

>数値用の演算子を転用するのは(あってはいけないというわけではないが)、
>「あんまりじゃ」、という感じがする。
>  
>

まあ、そのようにお感じになることには特に意見などはございませんが

>「Date.today >> 1」で直感的に「月の増加」であると理解するのは困難。
>また、「Time.now >> 1」は使えない。
>
>「Date.today + 1」は1日後を返すが「Time.now + 1」は一秒後を返す。
>Timeクラスでもinc_month(n)やinc_day(n)を作っておけば日付の処理がクラスが
>違っても統一的に行えるようになる。
>  
>

これは納得できません。

現状、 Time と Date がなんらの継承関係を持っていないのは「同じ処理を期待
するな」という意思表示だと思います。違いますか?

だいたい Time#inc_day の実装は閏秒や夏時間が影響することを考えると、容易
ではないでしょう。

Date と Time が同じメソッドを持っていることは必ずしも人類を幸福にしない
と考えています。

# メンテナ諸氏がどう考えておられるかは存じ上げませんけれども。

>日付クラスなので、年月日を分けて処理できるメソッドがあってもよい。
>日付クラスなので、year、month、day などの名前を含むメソッドがあってもよ
>い。
>  
>

まあ Date#year というメソッドは実際に存在するので、あってもよいというの
はそのとおりなのでしょうね。

>実務的(報告書の作成や、期限の判定など)では「xヶ月後のxx日しめ」とい
>うような日付は良くでてくる。従って、短くて、分かりやすいほうがよい。
>
>次のように書いた方が分かりやすい。
>
>raigetu_25niti = Date.today.inc_month(1).set_day(25)
>#                今日から見て 1ヶ月後の  25日
>  
>

そのような処理こそ Domain Specific なわけで、あえて標準で用意するほどの
ものなのか? という点に関して疑問に思います。

あと set_date という名前がかなり嫌いです。Date のインスタンスは
immutable であるべきです。