大塚屋（武蔵関）
明日，O川氏が引っ越す前に飲み会をするとのことで，それに持って行く酒を買いに行った．何を買ったかはまだ秘密．
嬉しいことにすっかり顔が覚えられていて，店主と奥さんといろいろ話をする．同じ酒米でも育て方によって味が違うので，これからはどこが作ったかが重要になるとか，最近強力米に注目しているとか，吉祥寺のラーメン屋の源宗近がここから純米酒を仕入れて使っているとか，月曜日に某蔵元を連れて松の屋に行くとか．秘密の話とか，秘密の酒の話もあり．
なお，先日の松の屋のどぶ祭りでは，普通の酒の会なら2合換算ぐらいの追加注文が来るらしい（＋蔵元持ち込み分を飲むことになる）が，るみちゃんから5合換算ぐらいで注文が入り，さらに実際に店に行ったらとんでもない酒豪ばかりで瞬く間になくなりびっくりしたとのこと．逆に「普通の酒の会もあんなに飲むんですかね？」と聞かれてしまった．さすが，二升ガールズ達である．今回は奥さん一押しの日置桜 強力生もと純米は買えなかったので，また今度来よう．
業務連絡：明日は4号瓶2本と燗酒用具を持ち込む予定．もしかすると，ウクレレもあり？（笑）
?SR-310
A氏とkyuka氏から概要の説明があったこともあり，S庭氏とkyuka氏が文句を言っていた某?SRのMLに登録して，そのプレゼン資料と?oda timeのAPIを見てみた．なお，これはまだ単なる個人的なメモなので，まともなところからはリンクしたりしないように．
- Dateクラスはバージョン1.1から単なる時刻を表すオブジェクトに大きく変化したので，そもそも大部分の機能はdeprecatedと宣言されているので，それに文句を言っても意味はない．
- 彼らが問題にしている「イケテナイところ」は何かを考えてみたが，現在のAPIでは，大きく分けて時刻（longで表されるミリ秒値又はDateオブジェクト），暦の計算（Calendarクラス），暦の文字列化（DateFormatクラスなど）に分類できる基本機能を，ひとまとめにすることで簡略化を図ろうとしている気がしている（が，彼らの意見にいろいろ矛盾があり，定かではない）．
- 現在ではDateクラスは時刻を表すオブジェクトであり，Calendarクラスはそれを操作する．問題は，Dateクラスを大規模な変更したにもかかわらず，過去との互換性を保つために，実際の実装は結構込み入ったコードになっていることであろう．ただし，API的には非常に単純．
- 時刻とその操作をひとまとめにすることは，概念的には単純で理解しやすいかもしれないが，いくつかの問題が発生すると思われる．一つは，常に世界の時刻に対応できる暦オブジェクトを生成するとなると，サーバ内部で使うには重すぎるのではないかということ．たとえば，暦オブジェクトは共有し，時刻オブジェクトだけを毎回生成する方がかなり軽いのではないか．もう一つは，時刻オブジェクトを分離しておけば，その後他の方法で表された時刻も表現できる可能性が出てくること．たとえば，現在の実装では，随所でlong値を介しているために，表現できる日時の範囲が制限されるかもしれない（未検証）が，この制限を大幅に緩和した時刻オブジェクトも使えるかもしれない．
- 時刻表現の実装がダーティという点を除けば，個人的には時刻と暦を分離してもかまわないと思う．歴史的経緯による汚い部分を直したいというのは，単なる趣味の問題で，顕著な実益はないように思う．
- 彼らの発表資料にスレッドセーフではないという指摘が何度もあるが，本当は多くの人に要求されているのはライブラリをリエントラントに設計することではないか？（未確認）つまり，複数のスレッドが，一つの暦オブジェクトを共有し，時刻を与えながら同時に使いたい（そのために内部状態を共有しないように実装する）ということであり，（これがまだ出来ていないとしたら）検討する価値がある．しかし，実際には機能と状態が複雑なので実現は難しそうである．下手に内部でロックを導入されても意味がない上に性能が落ちてStringBufferの二の舞になるので，スレッドごとに暦を持つのが妥当か．なお，時刻と暦を統合したら，これはそもそも不要のはず．
- 使いにくさの一つは，暦の操作にあるのではないかと思う．現在のsetメソッドのような部分を再検討するのは有効．ただ，?oda timeの命名規則は，あまり趣味がよいとは思えないし，逆に煩雑すぎる．IDEによる入力支援を考慮に入れた，簡易メソッドを追加するとよいかもしれない．
- プレゼン資料で指摘されているような，Calendarで値を操作しても，一旦Dateオブジェクトに変換しないといけないのは，確かに一考の余地がある．効率的にもCalendarオブジェクトを使った場合にはDateオブジェクトを介さずに渡した方が良いかもしれない．つまり，時刻取得→Dateオブジェクト作成→DateFormatと同様に，日時表現→Calendarオブジェクト→DateFormatというパスを用意するわけだ．問題は，ロケールの矛盾が発生する可能性があることだが，その場合はカレンダー側を優先するとか．
- DateだけでなくCalendarもimmutableであるべきというのは，矛盾した主張．時刻オブジェクトがimmutableで，暦オブジェクトがmutableということなら理解できるが…．そのわりには，?oda timeの実装方針は違うし．
- ?oda timeのIntervalやDurationやPeriodなどは上位概念であり，現状のままでも実現可能．ただし，本当に開発者が欲しいかはわからん．
- 月，日，曜日に対して，別々のクラスが本当に欲しいか？まだ意図が見えない．単にクラス数が爆発するだけでは？
- ?oda timeの実装がイケテナイのは，なんとなく分かった（笑）．
- 基本的に，何をおこなえば，性能向上，重要・本質的な機能拡張（現状の延長でも可能なものは除く），実装の容易さなどのはっきりした利点が生じるかの議論がしっかりおこなわれていないように思う．単に趣味じゃない・キレイじゃない程度の理由で，基本クラスを入れ替えるのは無謀なわけだし（それを言い出したら，捨てたいクラスがかなりあるわけだし（苦笑））
