Aspect Group or Aspectual Inheritance
ある concern に対して、複数の実現方法（アスペクト）があるとすると、そのアスペクトは、その concern に対してのグループを形成していることになる？
たとえば、ロギングの concern を考えてみると、ファイルにログするアスペクトとコンソールにログするアスペクトの二つが考えられる。また、これらのアスペクトはお互いに排他的であるとも考えられる。つまり、片方のアスペクトが活動中（アドバイスがオン or 実行される）の場合には、もう一方は、活動を停止した状態（アドバイスがオフ or 実行されない）になって欲しい。このような concern の見方は、どれくらい一般的なものなのだろうか？
AspectJ では、上記のようなことを行うための実装は可能だと思うけど（詳しくは僕の AspectJ の ドキュメント を参照。「Exclusive Aspect」とか「Deployment」とか）、いささか無理をした実装方法にも思える。
Caesar では、ダイナミックデプロイメントがサポートされているので[*1]、AspectJ よりは、場合によっては、自然な実装が可能に思える。
AspectJ は、Caesar と比べると、かなり static な印象を受ける。AspectJ の 特徴と Caesar の特徴の中間には、Object Teams があるかもしれない。Object Teams は、AspectJ や Caesar とはちょっと違うけど、アスペクトのダイナミック性（？）の視点から気になる言語的な特徴として、アスペクト（Object Teams の用語でいえば team）のアドバイス（Object Teams の用語でいえば Callin binding）のオン/オフを直接アスペクトに対して行える点がある。
or Caesar にみたいに deploy を使って
myTeam.activate();
なぜこの機能が気になるかというと、（上で紹介してみたような）最近書いていたいくつかのドキュメントに共通していることは、Object Teams での activation/deactivation を AspectJ でエミュレート（シミュレート？）している点。僕が紹介したような Tips がどれだけ現実的かどうかわからないけど、言語的な特徴として AspectJ にあったとしたらどうだろう、という気はする。良い視点ばかりから眺めているから、もし採用することでどんな悪い点があるのかは不明だけど。
deploy(myTeam) {
...
}
話がちょっとずれたけど、もし、グループ的なアスペクト（or concern）が、十分に一般的なものであるのなら、もっと明示的な言語的なサポートがあってもいいかも？ オブジェクト指向では、恐らくそんなグループ的なものを扱う機能としては、継承が対応するのかもしれない。ロギングの例を考えてみると、LoggingAspect がロギンググループをあらわすとすると、そのアスペクトを継承して ConsoleLoggingAspect とか FileLoggingAspect とかで表せるかもしれない。
Caesar のダイナミックデプロイの機能の方が自然なのでコードでもっと具体的に表すと
deploy( getLoggingAspect() ) {
appMain();
}public LoggingAspect getLoggingAspect(String type) {
return ...;
}
みたいにできると思う。でも、デプロイされている 最中に アスペクトを交換したい（たとえば、コンソールからファイルに変更）となったら、どうやってそれを実現できるんだろうか。回避策はあると思うけど、それはうまいやり方なのか、それとも単なる回避策なのだろうか。言葉で遣りたいことを表現したとすると[*2]「あるアスペクトがオンになったらその他のアスペクトはオフになる」となる気がする。
もう一つ気になる点は、deploy が
Object obj = ...
みたいに Object の方でインスタンスを扱っているように見える点。Caesar のロギングで紹介したコードでは、LoggingAspect getLoggingAspect(String type) みたいに、戻り値を明示的に LoggingAspect にしているから、ある種のエラー（ロギングに関係ないアスペクトを返せる）は避けられると思うけど、これについても、うまいやり方なのか、単なる回避策なのか、どっちだろうか？
まとめると:
- お互いに排他的であるような concern とその実現のアスペクトのようなものは、どれだけ一般的なのだろうか？
- ある concern を実現するためのアスペクトのグループを表現する方法 or 現実的な有効性はあるのだろうか？
- Caesar におけるようなダイナミックなデプロイは有効に思えるけど、デプロイ後のアスペクトには、やや static 感を感じる。デプロイ実行中に、現在デプロイされているコンテキスト（アスペクト）を変更するような機能は、有効だろうか？
- アスペクトを明示的にオン/オフにできる機能は、有効だろうか？
- deploy に渡されるアスペクトを何らかの性質（型とか）で制限するのは、意味のあることだろうか？
リソース:
- Erik Ernst and David H. Lorenz. Aspects and Polymorphism in AspectJ. In Proceedings of the 2nd International Conference on Aspect-Oriented Software Development. (2003)
http://www.ccs.neu.edu/home/lorenz/papers/aosd2003polyspect/
- Cristina Videira Lopes, Paul Dourish, David H. Lorenz, Karl Lieberherr. Beyond AOP: Toward Naturalistic Programming. To appear in OOPSLA 2003 Special Track on Onward! Seeking New Paradigms & New Thinking.(2003)
