koichikさんやひがさんが
指摘されているように、確かにDSLとしてのJavaの表現力は非常に弱いです。
それは、Java で DSL ぽいことをやるフレームワークを実際に書いた当人である
私は、すごく実感しています。
LiQ Containerを作りながら、何度「mix-inしてぇー」と叫びたくなったことか。
私も、「全て」の設定情報や定義情報をJavaで表現すべきだとは思っていません。
そこでJavaで勝負しようとするのは辛すぎます。
プログラミング言語をDSL的に使うという点では、Rubyとかの方がずっと能力が
高いと思います。
ただ、私がそれでもDIコンテナの設定にJavaコードを使うのが良いと
思うのには以下の2つ理由があります。
1. DIコンテナが扱う設定情報の多くがJavaクラスに関するものである
2. Javaクラスという情報を扱うのに、Eclipse JDTというツールが使える
ある情報を表現する記法の是非を問うときの観点として、記法自体の能力と同じくらい、
その記法を記述するのに使えるツールの善し悪しは重要だと思います。
もし、Javaコードを書くツールがメモ帳とjavacしかなかったら、
Javaで設定書こうなんて言い出してなかったと思います。
たとえば、私は結構 Excel VBA マクロをよく使うのですが、
別にVisual Basicの文法が好きで使っているわけではありません。
いまさら言うまでもないことですが、Visual Basicの文法は完全に腐っています。
にもかかわらずExcel VBAが「それでも使える」と思う理由は、
エディタの存在です。軽快なエディタが、Excelインストールすると
デフォルトで付いてきてAlt-F11を押すだけで起動すること、
イミディエイトペイン経由で現在のExcelオブジェクトの状態を
簡単に見られること、デバッガが軽いことなどが Excel VBA を救っています。
私は、あるツールの善し悪しを決める要素として、そのツールの機能の成熟度
も、もちろん大事なのですが、ツールのセットアップにかかる手間も結構大事
だと思っています。Eclipseプラグインだったら、デフォルトで入っているJDT
のようなツールが十分使えるなら、それが一番いいし、入っていないなら、
ダウンロードしてインストールしなければいけないプラグインよりも、
ちゃんとupdate siteが用意されているプラグインの方が良いと思います。
それは、単純にセットアップがめんどくさいという理由だけで
そう思うわけではなくて、デフォルトで入っているツールは、それだけ
多くの人に使われて、叩かれて、磨かれていると思うからです。
実際、JDTの成熟度は凄いと思います。
DIコンテナの設定がJavaで十分簡潔かつ宣言的に書けるのであれば、
Javaで設定を書いてJDTで編集するほうが、
XMLで設定情報を書いて、裏でJDTを利用する特別なプラグインで編集するよりも
良い、というのが私の立場です。koichikさんとはちょうど真逆の立場ですね。
そんなわけで、「Javaで十分簡潔かつ宣言的に書ける」という仮定を成り立たせる
ことができるかどうかがLiQ Containerの生命線になってくるわけです。
あらゆる設定情報を書ける必要は全然なくて、DIコンテナの設定さえできれば
問題ないのです。
いまのところ、良くある設定のパターンに関しては、
かなりいい線いってんじゃないかと自分では思っていますがどうでしょうか?
拡張性に関して、クリアしなければいけない課題をいくつか抱えてはいますが、
それはalpha2である程度改善したいと考えています。
尚、私がこのような立場をとっているのは、
多分私があんまりEclipseプラグインとかを書けないということも関係があると
思います。もし、自分にものすごい勢いでハイクオリティなプラグインを作る能力が
あったら、もしかしたら全然違うこと言ってたかもしれないですね。
指摘されているように、確かにDSLとしてのJavaの表現力は非常に弱いです。
それは、Java で DSL ぽいことをやるフレームワークを実際に書いた当人である
私は、すごく実感しています。
LiQ Containerを作りながら、何度「mix-inしてぇー」と叫びたくなったことか。
私も、「全て」の設定情報や定義情報をJavaで表現すべきだとは思っていません。
そこでJavaで勝負しようとするのは辛すぎます。
プログラミング言語をDSL的に使うという点では、Rubyとかの方がずっと能力が
高いと思います。
ただ、私がそれでもDIコンテナの設定にJavaコードを使うのが良いと
思うのには以下の2つ理由があります。
1. DIコンテナが扱う設定情報の多くがJavaクラスに関するものである
2. Javaクラスという情報を扱うのに、Eclipse JDTというツールが使える
ある情報を表現する記法の是非を問うときの観点として、記法自体の能力と同じくらい、
その記法を記述するのに使えるツールの善し悪しは重要だと思います。
もし、Javaコードを書くツールがメモ帳とjavacしかなかったら、
Javaで設定書こうなんて言い出してなかったと思います。
たとえば、私は結構 Excel VBA マクロをよく使うのですが、
別にVisual Basicの文法が好きで使っているわけではありません。
いまさら言うまでもないことですが、Visual Basicの文法は完全に腐っています。
にもかかわらずExcel VBAが「それでも使える」と思う理由は、
エディタの存在です。軽快なエディタが、Excelインストールすると
デフォルトで付いてきてAlt-F11を押すだけで起動すること、
イミディエイトペイン経由で現在のExcelオブジェクトの状態を
簡単に見られること、デバッガが軽いことなどが Excel VBA を救っています。
私は、あるツールの善し悪しを決める要素として、そのツールの機能の成熟度
も、もちろん大事なのですが、ツールのセットアップにかかる手間も結構大事
だと思っています。Eclipseプラグインだったら、デフォルトで入っているJDT
のようなツールが十分使えるなら、それが一番いいし、入っていないなら、
ダウンロードしてインストールしなければいけないプラグインよりも、
ちゃんとupdate siteが用意されているプラグインの方が良いと思います。
それは、単純にセットアップがめんどくさいという理由だけで
そう思うわけではなくて、デフォルトで入っているツールは、それだけ
多くの人に使われて、叩かれて、磨かれていると思うからです。
実際、JDTの成熟度は凄いと思います。
DIコンテナの設定がJavaで十分簡潔かつ宣言的に書けるのであれば、
Javaで設定を書いてJDTで編集するほうが、
XMLで設定情報を書いて、裏でJDTを利用する特別なプラグインで編集するよりも
良い、というのが私の立場です。koichikさんとはちょうど真逆の立場ですね。
そんなわけで、「Javaで十分簡潔かつ宣言的に書ける」という仮定を成り立たせる
ことができるかどうかがLiQ Containerの生命線になってくるわけです。
あらゆる設定情報を書ける必要は全然なくて、DIコンテナの設定さえできれば
問題ないのです。
いまのところ、良くある設定のパターンに関しては、
かなりいい線いってんじゃないかと自分では思っていますがどうでしょうか?
拡張性に関して、クリアしなければいけない課題をいくつか抱えてはいますが、
それはalpha2である程度改善したいと考えています。
尚、私がこのような立場をとっているのは、
多分私があんまりEclipseプラグインとかを書けないということも関係があると
思います。もし、自分にものすごい勢いでハイクオリティなプラグインを作る能力が
あったら、もしかしたら全然違うこと言ってたかもしれないですね。