日々の破片

_ C#ジェネリックの確認

別に確認するまでもないが、.NETのGenericsがシンタックスシュガーではないことを確認してみた（追記：つい<T>をそのまま書いてブラウザーに食われていたので修正）。

    public static void Main() {
        List<int> lg = new List<int>();
        lg.Add(4);
        System.Collections.ArrayList lo = new System.Collections.ArrayList();
        lo.Add(4);
        System.Console.WriteLine(lg[0] + (int)lo[0]);
    }

単なるシンタックスシュガーであれば、lgとloに対して生成されるILは同一になる。しかし、実際には異なる。

  IL_0001:  newobj     instance void class [mscorlib]System.Collections.Generic.List`1<int32>::.ctor()
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  ldc.i4.4
  IL_0009:  callvirt   instance void class [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)

loc.0にnewしたList<int>のインスタンスがセットされ（IL_0006のstloc.0）、次のAddメソッド呼び出しのために、IL_0007でloc.0からスタックへロード、IL_0008で即値4がスタックへロードされ、Addメソッドの呼び出しとなる。

  IL_000f:  newobj     instance void [mscorlib]System.Collections.ArrayList::.ctor()
  IL_0014:  stloc.1
  IL_0015:  ldloc.1
  IL_0016:  ldc.i4.4
  IL_0017:  box        [mscorlib]System.Int32
  IL_001c:  callvirt   instance int32 [mscorlib]System.Collections.ArrayList::Add(object)

一方、ArrayListのほうは、即値のロード（IL_0016）の後、ボクシングがスタックに積まれた4に対して行われる（IL_0017）。
インデクサによるアクセスでも同様である。

  IL_0022:  ldloc.0     // ジェネリックリストのロード
  IL_0023:  ldc.i4.0    // インデクサの引数0のロード
  IL_0024:  callvirt   instance !0 class [mscorlib]System.Collections.Generic.List`1<int32>::get_Item(int32)
  // 戻り値はスタックトップに置かれる
  IL_0029:  ldloc.1     // ArrayListのロード
  IL_002a:  ldc.i4.0    // インデクサの引数0のロード
  IL_002b:  callvirt   instance object [mscorlib]System.Collections.ArrayList::get_Item(int32)
  IL_0030:  unbox.any  [mscorlib]System.Int32 // スタックトップに置かれたボクシングされたintのアンボックス化

というよりも、MSILは読みやすくていいなぁ。

_ かんたんRuby on Rails読書記録

ムムリクさんの10日間（いくつかはスキップされたみたいですが）の読書記録が終結されたようです（レイルは続くよ―最初が8月31日）。

著者としていろいろ教えられたり、素直に嬉しかったり、うーむと考え込んだり反省したりと、たくさん得ることがありました。どうもありがとうございます。

正誤表の充実にご協力くださったことにも感謝します。

_ この次は

はらいそ(細野晴臣&イエロー・マジック・バンド)

去り行く足音……が、立ち止まってこちらを振り向き「この次はモアベターよ」って、これだっけ？

小森のおばさんはどうでも良くて、ふざけた野郎だと思ったが、でも確かによっしゃやったぜ、と思ったときほど(不正確な表現だがまあいいや。永遠に完璧だと感じるこたないだろうし)、この次はモアベターよ、と言いたくなるものかも。

_ 雑誌とテレビ

なんでテレビ局ってなくならないんだろうと思ったけど、番組が打ち切られたりってのはあるな（番組＝連載記事と考えると、雑誌＝テレビ局だけど、そりゃ確かに違う）。

_ インターフェイスと実装のペア

C/C++のヘッダファイルと同じようにこのペアを考えるというのは感じたことはないが（というか、慣習って嫌みなのかな？ 原文もhabitだし）確かに、インターフェイスドリブンで作るのに抵抗を感じないだろうな、という点では同意できる。

同じく必要もないのに（特にアプリケーションで）インターフェイスを作るのはあれですなぁ、というのも同意できる。無意味じゃん。

あるコンポーネントをすさまじく汎用的に作っておき、ファクトリメソッドからの取り出し方法によってさまざまなインターフェイスを返す。それぞれのインターフェイスはファサード（ゲートウェイのほうが正確かな？ アプリケーションプロトコルの変換をするんだからゲートウェイっぽい）になっているのだが、相互にキャストはできない（QIすらできなくて良い。利用者には一貫したAPIセットを提供するほうが、混乱は少ないだろう）。

ただ、あまりに汎用的に作ると、結局、個々のインターフェイス（ここではAPIセットの意味なので、言語仕様上ではクラスそのものでも良い）ですべての処理を行う必要がでてきて、結局、API（システムAPI）の上のAPI（ここが内部コンポーネント）の上のAPI（ここがインターフェイス）という間の抜けた構造になってしまうので、どのあたりで切り分けるかが興味深い点。たとえば、.NETのStream一族とJavaの%putStream一族のデザイン上の相違とか。

_ アジャイルの押し付け

うーむ、アジャイルというのは雲のように湧き立つものなのだろうか。

良く晴れた午前中に山のある場所を散歩していると、良く見ることができる。山の木々の間から雲が生まれてくるところをだ。雲は決して天から降ってくるのではない。生気ある自然の中から、ごくあたりまえに生まれて、そして上って行く。それは生き生きとしたものだ（と、すっかりアレグザンダーに毒されて、生き生きとという言葉に対するわだかまりが多少は雲霧消散（おいIME、このくらいの慣用語は変換しろよ――と思ったら雲散霧消の覚え間違いだった）しているらしい）。

アジャイルというのは、そういうものだとマーティンファウラーは思っているらしい。

そして、僕も、それは正しい考えだ、と思う。

でも最初にキャズムを超えたと書いている。

だったら、それはしょうがないんじゃないかという気もする。だって、雲は天に集まり雲海となり、そして天から地上へ向けて雨を降らす。キャズムを超えたなら、そりゃ雨も降ってくるだろう。

降られたほうには災難ではある。

そこで、われわれには2つの手段が残されている。

1つは傘を用意しておくことだ。

そしてもう1つは唄うことだ。

雨に唄えば 50周年記念版 スペシャル・エディション [DVD](ジーン・ケリー)

What's a glorious feeling, and I'm happy again,

幸福を取り戻せるかも。