多分あなたは不都合な方法でこれについて行きます。あなたが言っていることに基づいて、アノテーションにコードを挿入すると言われるアノテーション固有のコードを挿入するツールが必要です。ロンボクを使用したいのは、ASTでハッキングするアノテーションごとにカスタムの手続きフックを書くことができるからです。あなたはそのようなフックを書くことの不便さに不平を言うようです。
あなたがソース - ソース変換を持っているProgram Transformation Systemを使用する場合は、非手続き、理解しやすいように、これらの「フック」をコーディングすることができるかもしれません。
if you see *thispattern*, replace it by *thatpattern*
(私はこれらの性質を持つDMSと呼ばれるプログラム変換システムを構築し、私のバイオを参照してください):ソース変換するために、ソースをこのように表現されています。メソッドの呼び出しのログを挿入するDMSソース - ソース変換は、ロギングのためにマークされたかもしれない:をinsert_call_logging
domain Java~v8;
rule insert_call_logging(p: access_declarations,
t: type,
m: IDENTIFIER,
a: arguments,
s:statements):
method_declaration -> method_declaration
" @LogCalls \p \t \m(\a) { \b } "
-> " \p \t \m(\a) { Log(\tostring\(\m\)); \b } ";
ルールメソッドがメソッド名にメタ変数Mを結合し、結合認識メソッドの他の部分を他のメタ変数に変換します。 "はmetaquotesであり、 ルールプロセッサは、ルール言語の文法からJava構文を区別するのに役立ちます。
何このルールはありませんが、具体的LogCallsを注釈されている方法を探し、そしてによってそれを置き換えるですメソッド名の文字列(\ tostring(\ m))を持つロギング呼び出しがメソッド本体の最初のステートメントとして挿入されています。
パターンを直接表現することは、構造ツリーの上下に登るカスタムコードをたくさん書く必要はありません。あなたがASTの形についてあまりにも多くのことを知っているので、実際にはかなり痛いです。
注釈信号をパターン に直接含めると、カスタムコードを注釈プロセッサに付加する必要はありません。指定したアノテーションが存在しない限り、ルール自体は起動しません。
このルールは十分複雑ではありませんが、必要に応じてさらに複雑なルールを書くことができます。これにより、任意に複雑なものを挿入したり、任意の複雑な方法でコード構造を変更することができます。
これにはいくつかのPTSがありますが、さまざまな程度までこれを行うことができます。(間違いなく、ソースからソースへの変換をしないので、ロンボクは弱点の1つです。
なぜこれを2回行う必要がありますか? 「ロンボク」のプロセスを一度走らせて、どこで実行できたらいいのですか? –
私が言ったように、注釈を使って挿入したいコードは、かなり異なるかもしれません。 AST変更を生成する手順を自動化したい – Julien
はい、私はAST変更についてのポイントを理解しました。 ASTの変更を2つの異なる場所に実装する理由を説明していません。 –