日々の破片
| 著作一覧 |
2007-06-20
_ RHG読書会での推薦図書
山下さんとcut-seaさん（実は名前知らない）がおもしろいおもしろいかわいいかわいいオリザ最高、いきなり会議で奥さんはまりまくりとか力説するので、あまりの迫力に押されてつい買ってしまって読んだ。
もやしもん(1) (イブニングKC)(石川 雅之)確かにおもしろいわ。（いきなり会議ってのは次の巻なのか?）
で、以降の巻も買うか、と思ってアマゾン見てると
もやしもん(5)おまけ付き (プレミアムKC イブニング)(石川 雅之)
が、
Amazon.co.jp ランキング: 本で2位とすごいことになっている。が、巻数が書いてないので、買えない。というか、人気あるんだな（本屋で平積みずーっとされてたのは見てるから人気あるってのはわかっていたはずだが、いかに、口コミが購買行動に影響するかを身をもって知るとか）。
で、もう一冊、口をきわめて賞賛してたのが
CPUの創りかた(渡波 郁)いや、おもしろそうだとは思っても、それほど興味はないわけだが、表紙もあれだし、しかしnobsunがでっかな声で、クロックを自分で決めて……（忘れちゃったが、なんかものすごくおもしろそうだということは良くわかった）……おもしろい！ とか断言すると、本当におもしろそうに思えるから不思議だ（題材的にはおもしろくないはずはないから、そりゃおもしろそうなわけだが）。
_ MD3
あとで書くつもり。
WPFはWPF。
Jasperは、レイトバインディング。ActiveRecordだなぁ。というか、レイトバインディングを主流にするつもりなんだろうか、とか。インテリセンスを実装するとしたら、初回アクセス時に取り出してキャッシュするとかかな。
LINQの本命はやはりペトポタか、というか、TableAdapterはどうなるんだろうかガクブル。
エンティティを中心に据えた場合（そもそもでもエンティティを構成するのは何かというのは目をつぶるのか、どうか）、ビジネスプロセスをどうそのエンティティにからめるのか？ という問題に対して、エンティティをオブジェクトとして多重継承でプロセスをからめる方法はオブジェクトグラフを固定化してしまうからあまりよろしくないのではないか、ではコンポジションでプロセスを挿入していくという方法はどうだろうか（そこにインターフェイスを決めるのか、それとも名前で決めるのか）、レイヤリングで分担ではどうか、アスペクトやデコレータによる外ざしはどうか、またはミキシンなど（オブジェクトではなく、関数の外ざし）はどうか、とか。書いてみると、いろいろな手法があるな。と書きながらふと思ったが、そもそもCでやってれば、全部関数テーブルでシンプルに解決するように思えてきたけど。
そのあと、NyaRuRuさんやakirameiさんや荒井さんと談笑。生成したTypeはアンロードできないのでAppDomainごと殺して解放する野蛮な手法とか、それに対してDynamicMethodとか（記憶違いかも）。
#メモのつもりが結構、長い。
ジェズイットを見習え |
Amazonランキングで上位になっているのは、もうすぐ発売の<br>5巻ですよ。4巻のときの限定版で大騒ぎになった(数が少なかった)せいもあるかも。<br>今みたら「在庫切れ」になってますね。<br>konozamaが起きるかも。
おお、それはラッキーかも>在庫切れ<br>実はよくわかってなかったわけですが、そこまで人気があるなら悪いこともあるまいと、なんとなく予約してしまったのでした。（アマゾンの予約はあてにならないことも思い出したけど、まあいいか）。<br>というか、()の中に書いた状態が起きることを、http://d.hatena.ne.jp/keyword/konozama というのですかそうですか。
え、その通りでございます。記憶違いではありません。<br>この辺りは、将来でも改善して欲しいなぁと私は考えています。後は、DLRに関してというかをhttp://blogs.msdn.com/shozoa/に少しずつまとめていきます。
URLありがとうございます。<br>でも僕は、解放できないほうが正しいと思うのですよ。だって、一度登録されたタイプが無くなるって世界の信頼の根幹の崩壊のようなものではないですか(AppDomainの削除は世界の崩壊そのものだからOK)。Type.getType(string)があるからユーザーコードでの参照の有無だけでは解放可能性も判断できないし。と思ったけど、明示的に削除するのもユーザーの責任かな？ 確かに（多分、今後進みそうな）動的な世界ならそれもありかも知れないですねぇ。
ここらへんはどうしたらいいんですかねぇ＞Typeの消滅<br>そもそもにあとからメソッド足す事を思えばruntime exceptionは受け入れているとも言えますが…<br><br>一方でclassを再evalしたらインスタンスの挙動が変わってくれないとeditorなんか作ってると厳しかったり(scratchでevalして挙動が変わらないemacsなんて…)。
メソッドを含めた属性の変化までを許容するか、Typeの変化までを許容するかのデザインってことなんでしょうね。<br>C++（今はどうか知らないけど）と違って実行時のTypeの追加まで許容してるんだから、削除もあって良いのかも。（で、System.Stringや、System.Int32とかを削除して恐ろしいことになるとか。でも、それはそういう環境であると。すごい自由だ）
そうなんです。ジレンマを感じる点もあります。動的にコードを作る世界だとヒープの肥大化を招きますますので、必要に応じてクリーンアップする手段も欲しいと私は考えているだけです。常に使いましょうと進めるものでもありません。
昨日はお世話になりました．<br>以下 CLR の型情報が解放不能リソースであることを示す例です．<br>http://d.hatena.ne.jp/NyaRuRu/20060801/p1<br>http://d.hatena.ne.jp/NyaRuRu/20060731/p1<br># Generic type が 100 段ネストで実行時例外，というのが妙におもしろかったり．64 でも 128 でもなく 100 なのか，と．
こちらこそありがとうございました。<br>それにしても、本当に100ですね。メッセージも適切だし(余裕をもって開発したんだろうな)、おもしろいです。
皆さん、有難うございます。<br>本当にそうですね。型情報が開放不能リソースであることを記憶の片隅に留めておかなきゃいけないんですよねー。