-include＆namespace
ちょっと多忙にまぎれてましたが、includeメカニズム仕様について新案をまとめたいと思います。適宜つっこみください。
直感的には、子コンテナに進めば進むほど影響範囲が小さくなるほうがわかりやすいと私は思ってます。コレが今の仕様と決定的に違うところですね。以下のコンセプトにまとめられれます。
- A include B include C とあるときに、AからはABCのコンポーネントが見えて、BからはBCのコンポーネント、CはCのコンポーネントのみ見える。そのとき、ABCの順にサーチしていくので、同じインターフェイスを実装したコンポーネントがABCそれぞれにあったとしても、見つかったところで解決。よって多層にコンテナを重ねてもTooManyにならない。
- A include B、A include Cとあるときは、BCのコンポーネントはA内のincludeエレメントの出現順でサーチして見つかったところで解決。よって「ユーティリティを集めた」的なコンテナを作って多用してもTooManyにならない。
なるべくTooManyにならないようにして、順番で検索して解決すれば、必要なときにincludeすればよしという形です。一方で名前空間は。。。
<include path="config.dicon" namespace="j2ee">のように名前空間の指定をincludeタグ側にもってくる。- 名前空間を利用した指定は、名前空間名+コンポーネント名 でやはり下方検索を行い、見つかったら解決。
以上だとプラグインも作りやすいです。今回私が直面した（すぐ原因がわかってワークアラウンドもできるけど）ストレスに感じたところをまず回避してみました。とにかく私が感じる現行仕様のストレスはコンポーネントが増えてくるとTooManyにすぐなっちゃうところです。コンポーネントを登録時にフラットな空間に全部集める作りなのでTooManyになってしまうケースが多いので、それなら集めない方がよいと私は思っています。インターフェイスでコンポーネントを自動登録し、そのインターフェイスで自動インジェクションされる動きがS2の特徴ですが、なるべくTooManyにならないほうがこの機能が強力かつ有効に動作するかと考えるのです。
この制限は残ったほうがいいと思います。
