netail.net

_ AspectJ ▲

さらに意見が出てた．これ，どこまで続くんだろう．

• Aspect には， "abstract" なアスペクトが，pointcut に join point と関連付けられていないという形式と，pointcut は定義されているが処理が定義されていない，という二つの形で存在している．これらを言語上で区別するべきではないだろうか．

_ AspectJ ▲

MLでの議論はまだ続いてる様子．

• Eclipse AJDT ではマーカーを表示してくれる．タグ付けで「ここでアスペクトが動く」っていうのを書くのはたしかに一見してわかるという利点はあるが，統合開発環境のサポートがないからといって言語が対応するというのは問題なのではないだろうか．

という感じの意見もあったりする．みんな色々考えてるんだなぁ．

_ AspectJ ▲

AspectJ-users メーリングリストで，AspectJ みたいな言語によるアプローチと，Java を拡張するフレームワークとで，どっちがいいんだろう？とかいう感じの話があった．まとめると，だいたい次の通り．

• アスペクトを複数のファイルに記述するとき，言語的な観点からは，導入する複雑さのほうが本来解決すべき問題の複雑さを超えてしまうかもしれない．
• JBoss グループでは，メタデータとインターセプタによってAOP を実装しているが，「AOP を実現するツールとしてのメタデータとインタセプタ」が，「AOP とはメタデータとインタセプタだ」ということに置き換わる恐れがある．
• デバッグのサポートは重要．アスペクトによって，予期せず到達したコードがある場合，「なぜそのコードにたどり着いたか」を知ることが重要となる．
• pointcut は単純すぎるとアスペクトの記述が難しくなる．たとえば，Control-Flow 記述を省略することでシンプルな言語を作ることはできるが，特殊な実行トレースなどを作るときに苦しむことになる．
• 補足的なアスペクトを追加するときは Java + XML が妥当に見えるが，アプリケーションで重要な（「補足的でない」）アスペクトを記述するときは，できるだけソースコード中に情報を書きたくなる．補足的なアスペクトだけを見ている人には，フレームワークのほうがわかりやすい．
• フレームワークのほうが導入しやすいが，使いにくい．フレームワークの動的な側面は，Java がリフレクションで利便性を得たのと同様に，便利な側面がある．
• XML によるdeployment の記述は，意外と難しい．また，アスペクトの情報が複数のファイルに分散するのも大変．アスペクトを別ファイルに書くくらいなら，xdoclet みたいに@xx という追加タグを埋め込んだほうがマシ．
• シンプルなフレームワークには魅力がある．しかし，ツールによるサポートなしでは厳しそうに見える．

……といったところ．全体では，AspectJ の方法のほうが良いと思ってる人は意外と多そうだ．Users メーリングリストなんだから当然かもしれないが．

_ スクリプト ▲

ゲーム用のスクリプトを作ってくれーと言われてるので地道に SableCC なんぞを調べているのだが，問題は言語の表現力．どうせ言語を作るなら，できるだけ抽象的に書きたいし，ゲーム向けの，確率テストや乱数発生，計算の扱いなんかを簡単にしてやりたい．どうせ Python/Java からコントロールされることになるのであとは外部関数呼び出し機能くらいか．もう少し仕様を詰めてもらわないと，方針が立たないので保留しておく．