頭のなかでモヤモヤとわだかまっていることがあるので、趣旨だけメモっておきます。
ちなみに、用語の使い方等はかなりいい加減なので、よい子は宿題のレポートをまとめる参考などには使わないように!
Javaの匿名インナークラスに強い気持ち悪さを感じる §
昔、C#とJavaを比較するという面白くもないレベルの低い議論があったときに、Java信者側から「匿名のインナークラスがあれば良いのだからdelegateなんか要らない」という意見がありました。
その時に私が感じたのは、匿名インナークラスに対する強い気持ちの悪さです。
クラス定義の中にメソッドの定義があり、その中に更にクラス定義があるのは、いかにもソースコードの見通しを悪くする俗悪な書き方に思えました。
特に、記述されたコードが、実際に実行される順序と一致しなくなるという問題は、シンプルで分かりやすいソースコードという趣旨に反するような気がしました。
が、しかし……。
JavaScriptの匿名関数は凄く気持ち良く感る §
Ajaxに絡まって、再びJavaScriptのコードを見るようになったとき、そこにJavaScriptの匿名関数がぞろぞろ出てきました。
まさに、「記述されたコードが、実際に実行される順序と一致しなくなる」というパターンに合致します。
しかし、それを見て、気持ち悪いと思うことはなく、それどころか気持ち良いとすら感じました。
どうして、同じような構造を有するソースコードを見て、Javaは気持ちが悪いのに、JavaScriptは気持ちよいのでしょうか?
データとコード §
非常に乱暴に要約してしまうと、プログラムは、データとコードから構成されます。
データとコードは、プログラム言語のタイプによっては厳密に分類され、コードをデータのように扱ったり、データをコードとして実行することはできません。しかし別のタイプのプログラム言語は、両者の境界が曖昧であり、相互に乗り入れることができます。
相互乗り入れできる言語の感覚でものを言えば、たとえば変数にコードを代入して、変数を経由して実行するというのは、しごく当たり前の処理となります。
そして、JavaScriptは紛れもなく後者の言語です。
つまり、匿名の関数を定義して、それを変数に放り込んで、あとからそれを呼び出して使うのは、ごく当たり前の自然な処理になります。これに気持ち悪さを感じるはずもありません。
おそらく、この手の関数は高階関数と呼ばれることもあるプログラム言語世界の立派な1機能と思って良いと思います。
それじゃどうして匿名インナークラスは気持ちが悪い? §
その理由を理解するためには、「プログラムはデータとコードから構成される」という主張を拡張する必要があることに気付きました。
これには致命的に欠落しているものがあります。
それは「型(データ型)」です。
「プログラムはデータとコードと型から構成される」という認識を持ったとき、匿名関数と匿名インナークラスの決定的な差が見えてきます。
つまり、匿名関数は「コード」であるのに対して、匿名インナークラスは「型」であるということです。
つまり、コードが匿名であることは良いが、型が匿名であることは気持ちが悪いということです。
振り返ってみれば §
そう思って振り返ってみれば、Cでも匿名の構造体や共用体は使わないようにしていました。やはり気持ちが悪かったのでしょうね。
ちなみに、型定義の一部を構成する匿名の型は使うことがあります。
なぜ匿名の型は気持ちが悪いのだろう? §
型というのは、データ、あるいは時としてコードの内容や性質を示すために付加される情報と言えます。データ、あるいはコードは、そこにある情報としての実体であるのに対して、型とは抽象的な概念上の存在であると言えます。(その抽象的な概念を具体化した実体としてのオブジェクトはあり得る)
具体的な実体が存在するものは、「これ」と指さすことができるので、実は名前が無くても何とかなるのです。しかし、抽象的な存在は、指さすことができない可能性があります。
たとえば、Cで以下のような匿名の構造体を使った変数を宣言したとします。
struct {……} foo;
ここで定義されている構造体を具体的に示す情報は、おそらく実行時にメモリ上に存在せず、ポインタで指し示すこともできません。名前で語ることができないだけでなく、指さすこともできないのです。この型について語る場合には、常に「変数fooの型として定義された構造体」という回りくどい言葉を必要としますが、回りくどい言葉はトラブルの温床となるリスクを持ちます。
まあ、Javaの場合は型に関するオブジェクトが内部的に生成され、それを指さしたり、リフレクションで活用することができるのかもしれませんが(未調査)、名前がないことは型について語る際に不便さを発生させます。そして、型について語ることが不便であるということは、型によって修飾されるデータやコードについて語ることの不便さにつながります。
結論とも言えない、いい加減な結論 §
つまり、この「語ることの不便さ」。そして、匿名であることにより入り込む「語りの曖昧化」が、どうやら私に気持ちの悪さを感じさせる正体であるような気がします。
そして、コミュニケーションの不可能性を自明の前提として据えた上で、あえてコミュニケーション可能性を高めるとすれば、排除可能な「語りの曖昧化」は排除するのが当然の選択ということになります。
ということが正しい答と言えるのかどうかは全く分かりません。
