netail.net

_ 論文 ▲

Joao Costa Seco, and Luis Caires:A Basic Model of Typed Components

コンポーネント主体の Java 拡張言語 ComponentJ を提案している．

component C is compose { provides IQueue q; // インタフェースを定義 requires IList list; meth mq { void enQueue() ... } plug mq into q;}といった感じ．通常のクラスはコンポーネント内部のローカルオブジェクトとしてしか利用できない．で，インタフェース間の接続時に，型の整合性チェックを行うことで型安全なコンポーネント利用ができるらしい．

コンポーネントのインスタンスはグローバルな singleton なのか，とか一つのコンポーネントを共用可能なのか，とか気になるところはいくつかある．

_ 論文 ▲

Jan Vitek, and Boris Bokowski:Confined Types in Java, Software Practice and Experience, 2000

Confined Class == 外部パッケージからは動的にも静的にもアクセス不可能なクラスAnonymous Method == this 参照を他の anonymous メソッドや自身のフィールドアクセス以外に使わないメソッド

というようにして，このルールが守られないのならエラーを出すというもの．通常のアクセス権設定の private/protected/public や，チェック漏れの可能性がある動的チェックでは十分ではないので，セキュリティ上の目的で導入している．

java.util や java.awt などのクラスの８割か９割くらいは最初から confined らしい．そうでないものも，気をつけて書けば簡単に confined になるらしい．

JVM や native メソッド等からアクセスされる可能性があるため，Throwable や Thread のサブクラス，public や protected で宣言されたメンバ変数の型はconfined ではない，としている．

_ 実際にはパッケージ単位だけでは不便なのでドメイン宣言というパッケージやクラス群をまとめた「ドメイン」内で confine を定義するなんていうことも考えているらしい． ▲

関連研究としては，外部からの参照を許さないオブジェクトのエイリアスの制御などがある．

利用例として，RSA 暗号において，乱数の値，秘密鍵ファクトリ，秘密鍵が Confined になるらしい．

_ 論文 ▲

Johan Brichau, Kim Mens, Kris De Volder:Building Composable Aspect-specific Languageswith Logic Metaprogramming,Proceedings of GPCE 2002

アスペクトの weaving を，論理型言語で記述した述語を使ってbefore(m, c) -- メソッド m の前にコード c を実行といった記述を書いて，アスペクトを合成する Combination Module とアスペクト間を連動させる Interaction Module を使ってアスペクトの組み合わせを構築した上で Weaver に与える．

Accidental に影響が出るようなことがないのなら，これで大丈夫だという気はする．アスペクトの合成が正しいかどうか，というところで検証系などとの組み合わせが必要になるのかもしれない．

_ 論文 ▲

Eric Allen, Jonathan Bannet, Robert Cartwright:A First-Class Approach to Genericity

C++ の mixin はマクロ同様にコード展開してから型チェック処理が行われるので本来の mixin 型の意味が失われてしまう．それを何とかしよう，ちゃんとルールを定義しましょう，というもの．今まで実はそういう研究はなかったのね，とちょっと驚いた．

_ 論文 ▲

John Corwin, David F. Bacon, David Grove, Chet Murthy:MJ: A Rational Module System for Java and its ApplicationsProceedings of OOPSLA 2003, pp.241-254

Java にはモジュール機構がないので，クラスパスの管理が大変．ライブラリ間の依存関係なども考慮しなければならないという問題に対して，module を明示的に定義して VM に与えることで管理してやろうというもの．import, export, seal, unseal, hide といったスコープ操作用の言語を作っている．アプリケーションのコンフィギュレーションを作ってしまえばそれを起動できたりするのでけっこうえらいかも？

_ 論文 ▲

Keunwoo Lee, Anthony LaMarca, and Craig Chambers:HydroJ: Object-Oriented Pattern Matching for Evolvable Distributed Systems

メッセージを処理する Service クラスを，従来ならメッセージループを自前で構成するところでpublic service class Foo { handler MSG_1 return void { ... } handler MSG_2 return int { ... }}といった感じで，各メッセージの処理を独立して記述できる．handler が反応するメッセージについては，semi-structured value というML における引数のパターンマッチみたいなのを導入している．

最近は EJB サーバみたいなのが働いてくれるわけだし，分散アプリケーションがこういう言語仕様の拡張でどの程度書きやすくなるかは疑問ではある．

_ 論文 ▲

Todd Millstein, Mark Reay, and Craig Chambers:Relaxed MultiJava:Balancing Extensibility and Modular TypecheckingProceedings of OOPSLA 2003, pp.224-240

AspectJ などで使える inter-type declaration 的なメソッド宣言と，特定の引数に対してメソッド実装を特化することができるmultimethod 定義が使える Java の拡張言語．モジュールごとの型チェックが特徴らしい．Multimethod は便利そうだけど，これもまた落とし穴になりそうな気はする．

_ 論文 ▲

Donal Lafferty, Vinny Cahill:Language-Independent Aspect-Oriented ProgrammingProceedings of OOPSLA 2003, pp.1-12

Weave.NET という CLI 上で使う AOP の実装．使っている Join Point Model などは AspectJ ベースで，アスペクトとして，XML による結合規則を記述して，対象コンポーネントをクラス(.NET Assembly)に接続する．コンポーネントとアスペクトをまったく別に記述するので特定言語に依存しない．

# やったらできそう，という意味ではあまり面白くないかも．

_ 論文 ▲

Bil Lewis, Mireille Ducass\acute{e}:Using Events to Debug Java Programs Backwards in Time.Companion of OOPSLA 2003, pp.96-97

プログラム実行情報を全部保存してしまって後戻り可能なデバッグをすれば楽なんじゃないか，ということでツールを作っているらしい．http://www.lambdacs.com/debugger/debugger.htmlから AADEBUG (International Workshop on Automated Debugging, 2003) の論文が取れたので見てみると，値がおかしくなったところで逆戻りして原因を捕まえるとかいうスライシングなどと同様の考えをしている．また，メソッド実行トレースや変数などから実行時点を探すといったこともできるようにしている．

しかし，Dynamic slicing よりも情報保存量は大きいはず，と思っていたら，実験では，0.1μsごとにイベントを取ったら20秒で2GBのアドレス空間がいっぱいになったとか，でも 64bits アドレスなら大丈夫だとかいう記述があった．物理メモリ量でごり押ししないと使い物にならないような気がする．いちおう動くものは作ってるらしいのだが．

_ 論文 ▲

Cristina Videira Lopes, Paul Dourish, David H. Lorenz, Larl Lieberherr:Beyond AOP: Toward Naturalistic Programming.Companion of OOPSLA 2003, pp.198-207

アスペクト指向とは何なのか，自然言語の役割はどこにあるのか，「アイディアをより自然な形で表現する」にはどうしたらよいのか，といったことを議論しましょう，という論文．

AOP の魅力的なところは何か，ということで，トレースの例を挙げている．今までは，「すべてのメソッドの先頭で Trace.in を呼んで最後に Trace.out を呼ぼう」と考えることはできても，そのために「メソッドＡの先頭で，...，メソッドＢの先頭で，...」と記述することしかできなかったが，AspectJ では「すべてのメソッドの実行の前と後で，...」という，より自然な表現で記述することができるようになった点にあるとしている．

アスペクトの役割を，アプリケーションを本にたとえるなら，オブジェクトの中で起こっていることを別の章に分けて書いておくとより簡単に説明が済んで，管理も楽になる，ということである．

AOP とリフレクションには深い関係がある．リフレクションを使って AOP を実装することが可能．しかし，通常のリフレクションはプログラム構造がベースで，Aspectual reflection は Join Points という実行上の時間要素がベースになっている（これは AOSD2003 の論文で述べていたことと同じ）．

Stream の Encoding の例を挙げて，「書きたいやり方」はこうだ，と書いている．

encodeStream(InputStream in, OutputStream out) {
  while there is data in in:
    read the first N bytes from it;
    perform encodeDuration on those bytes
      and write the result into out.  
    if, however, after reading the input,    
    the number of bytes read is less than N,
    then, before continuing, patch the     
    resulting byte array of size N with zeros.
}

プログラミング言語の特性は，何をどのようにプログラムから参照できるかにあり，Temporal Logic Programming は時間情報を，Functional Programming は関数と変数を，操作する．言語を設計する場合には，これが重要な決定となる．

_ 論文 ▲

Tanter et al.: Partial Behavioral Reflection:Spatial and Temporal Selectin of Reification. Proceedings of OOPSLA 2003 の続き．

Reflection は，計算処理のメタレベル視点を取るので解空間上で問題を考える solution-oriented アプローチであり，AOP は，問題を的確に表現する Domain-Specific なものを考えていることからproblem-oriented なアプローチである．しかし，アスペクト間のインタラクションなどの扱いが難しいのがAOP の欠点である，とも指摘している．Runtime AOP は Partial behavioral reflection のサブセットで，Reflection の機能をより使いやすく提供しているもの，と位置づけている．

Reflective アプローチも複数の言語をサポートすることができるらしい．Aspect-Oriented Logic Meta Programming をその例として挙げている．

_ 論文 ▲

\acute{E}ric Tanter, Jacques Noy\acute{e}, Denis Caromel, Pierre Cointe:Partial Behavioral Reflection:Spatial and Temporal Selection of ReflectionProceedings of OOPSLA 2003, pp.27-46

いわゆる Reflection でも，完全なセットを用意するとオーバーヘッドが大きくなる問題があるので，部分的な reflection で必要なところだけ引っ掛けるようにしたい．

空間的な選択肢として，次のようなものがある．

・対象となるエンティティ（特定のクラス，あるいは特定のインスタンスを選択）

・対象となる操作（メソッド呼び出しやフィールドアクセスなどのうちどれを使うか）

・操作間の関係（ある特定メソッドからの呼び出し，などに限定する）

時間的な選択として，オブジェクトのライフサイクルの特定の期間だけreflection を有効にするという方法がある．（空のメタオブジェクトよりは，reflection を無効にしたほうがコストが安いとする）

通常はクラスごとあるいはインスタンスごとのメタオブジェクトを作るが，この論文では，hoolsets を使う．これは AOP における Join points のようなもので，これを介して一つのインスタンスに複数のメタオブジェクトをくっつけることができる．

実装としては，

・クラスロード時にバイトコードを変形する．

・ClassSelector, OperationSelector, Active で対象となるエンティティ・操作・期間を選択する処理を定義する．

・Hooksets は上記のオブジェクトなどによって定義される．XML で，どの ClassSelector や Operation Selector を Hookset に関連付けておくかを定義し，さらに Hookset にメタオブジェクトを関連付ける．

実行時にコントロールできるあたりは，Event-based AOP などに近いかもしれない．

_ 論文 ▲

Phipippe Mougin, St\acute{e}phane Ducasse:OOPAL: Integrating Array Programming in Object-Oriented Programming.Proceedings of OOPSLA 2003, pp.65-77

配列操作を言語レベルの演算子にしてしまおう，というもの．ただし，配列操作といっても，オブジェクト指向なので任意のメッセージを配列の各要素に適用する，というものになっている．

Ruby 的に言うなら array.collect { |obj| ... } などに相当するが，これを繰り返し処理などを意識せずに使えるようにする．

提案している記法は @ を利用している．

(1) obj method @ array

(2) array @ method args

(3) array1 @ method @ array2

(1) は， array に入っている各要素について，それを引数として obj.method を呼ぶ．

(2) は，array に入っている各要素に対して，args を引数にして method を呼び出す．

(3) は，array1 と array2 のすべての組み合わせに対してmethod を呼び出す．また，Reduction としてバックスラッシュを使って配列のすべての要素の和や最大・最小といった要素をあらわせる．

{1, 2, 3} @ + 10 => {11, 12, 13}

{1, 2, 3} @ + @ {10, 20, 30} => {11, 22, 33}

{1, 2, 3} \#+ => 6

Employees (salary > 3000) \#+ => salary が3000より上の従業員の数

実際には配列以外の任意のコレクションが扱えるようになるとかなり強力な記法になりうる．

あったら迷わず使いそうだが，なんだか危険なにおいもする．配列の結合演算と各要素の加算を間違ったりすると悲惨そうだ．