netail.net

_ [work]PC返却 ▲

とうとう返却期限が近いので，新しいPCは未だ到着していないが，データのバックアップ→初期化→箱詰め．新しいPCが到着するまではデモ用ノートPCで作業する予定．といっても，デモ用PCにはPowerPoint以外のアプリケーションはほとんど入っていないので，テキストエディタとWebブラウザだけで作業できる範囲にとどまる予定．メール読み書きはWebメーラーで対処．

なので，原稿書きとかhyCalendarのアップデートとかの作業は一時停止．

_ [読書]賢者の国の魔法戦士，呪縛の島の魔法戦士 ▲

話の展開はすごく早いのであっさり読み終わり．高級マジックアイテムの強さがよくわかる．

話の本筋ではないけれど気になったのが，登場した呪われた島の住人が死ぬまで戦う様子．これは，かつて「ロードス島戦記コンパニオン」で，LPが０になった時点で即死だった（ソードワールドと違って生死判定がない）から？

_ [論文]ポイントカットの分類 ▲

Maximilian Stoerzer, Stefan Hanenberg: A Classification of Pointcut Language Constructs.

Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.

アスペクト指向の言語ごとに使えるポイントカットが違うので，ある目的の機能をアスペクトとして記述しやすいかどうかなど，簡単に判断することができない．そこで，ポイントカットとして使える要素を整理してみようというもの．

提案している分類は三つのタイプに基づいている．１つはSpecification-Based，プログラムの抽象化した情報（クラス名やクラス間の関係など，ソースコードから得られる情報）．２つ目は，State-Basedで，AspectJのifポイントカットのように，その時点での実行コンテキスト（アクセス可能な変数やスタックトレースの状態）に依存した情報．３つ目が，Process-Basedで，cflowやdataflowのように過去に通過した状態に基づいたもの．この分類はかなり直観的で好きかも．

３パートモデルを実装したインタプリタで，ポイントカットをこういった種類に基づいて，適用タイミングとかをあらかじめ分けておくと，複数のJoin Point Modelを混ぜたときに，きれいに収まるような気がしないでもない．３パートモデルにおける "weave" が，Join Point Modelに応じて違う作業（プログラムの実行orプリプロセス）を表現するのが気持ち悪いからそう思うだけなのかもしれないが…．

_ [論文]ポイントカットの条件式のコンパイル時評価 ▲

Tomoyuki Aotani, Hidehiko Masuhara: Compiling Conditional Pointcuts for User-Level Semantic Pointcuts.

Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.

何も考えずに（著者名見ずに）ざっくり眺めて，どこかで聞いた話だなーと思ったらSPA-SUMMERで聞いた話だった．

この手法は，うまく使うと，特定のメソッドを実装しているクラスは勝手に declare parent の対象になるとか，静的ポイントカットとの組み合わせで，何か便利な応用がありそうな気がする．コンパイラの負荷が上がるところは，個人的には，人間ががんばるかわりにコンピュータががんばってくれるほうが幸せなので，あんまり気にならない．

_ [論文]アクションと状態遷移の分離 ▲

Gurcan Gulesir, Lodewijk Bergmans, Pascal Durr, Istvan Nagy: Separating and Managing Dependent Concerns.

Proceedings of LATE 2005, Chicago, Illinois, March 2005.

Cで構築されたシステムで，状態ごとのアクションを実装した関数呼び出し＋状態遷移のための変数変更を羅列していたら，もし新しく関数呼び出しを追加したり，あるいは既にあるものを削除したり移動したりすると，それに合わせて状態遷移が正しく行われるかどうか毎回チェックしないといけなくなる．

そこで，状態遷移に必要な変数設定を，いつ行うか，ポイントカットとして定義することで，システム内部での操作と，状態遷移とを切り離している．ポイントカットとして，基本的には，（特定の関数内部で）どのような関数呼び出しが起こったときかを指定するのだが，状態遷移より前に起こるべき関数を列挙しても，その順番については言及しないことで，fragile なポイントカットになってしまうことをある程度回避している．アクションと状態の更新とを混ぜていた場合に比べて，どの関数の配置が自由であるか（状態遷移に関係があってそこに配置しないといけないのか，関係ないがたまたま配置されているだけなのか）を区分できるようになっている点は利点と言えそう．

また，Weave時に，関数によって生成される Join Point 列が変わった場合，その変化を開発者に通知することで，状態遷移図を描いた開発者が，自分が定義したポイントカット記述を必要なら修正できるようにしている．ベースコードの変更時にポイントカットの変更は避けられないことがあるなら，コード変更時に，ちゃんと関連するポイントカットの変更を検討できるようにする，という立場のよう．

_ AOSD まとめメモ／ポスターセッション ▲

ポイントカットを提案していたものでは，path expression pointcut と，block pointcut というのがあった．

path expression は，フィールドに格納されている参照を使って，obj.field1.field2 のようにたどれる範囲のオブジェクトを宣言できるようにしようというもの．target(p) ＆＆ path(obj -> p) のように記述することで，オブジェクト p を保有する obj なんかを変数に束縛できる．これは，DemeterJ とかで使っているtraversalの記法でもあり，強力な仕組みになる可能性はある

ただ，実現のアイディアについて聞いてみたら，ガベージコレクタなんかがオブジェクトの参照を見つけるような方法，といっていたので，かなりの力技になりそうな点が不安．成果が出てみないと何ともいえない．

一方の block pointcut は，東工大の人々による提案．エラーから回復するために，エラーを検出する特定の try ブロックを２つのポイントカット pcd-begin と pcd-end を使って block(pcd-begin, pcd-end) という形式で指定し，それに対して回復用のアドバイスをくっつけることを提案している．pcd-beginとpcd-endが同じブロック内にならないといけないという制約を付けていても，beginとendの対応が正しく取れているかどうか，コンパイル時にしっかり判定する必要があり，実装はけっこう難しそう．

そのかわり，ポイントカットの抽象度を向上させる可能性はありそう．たとえばファイル処理に関するブロックを pointcut FileProcess(): block(call(File.open), call(File.close))のような記述で記述すると，今までのようにbefore(): open と after(): close と書くかわりに，before(): FileProcess と after(): FileProcessと書いたりできる．これは，実装の詳細のメソッド名などを見せずにポイントカットだけを公開するために使えたりするかも？とちょっと期待．