0

変数の制約をチェックするための小さなDSLを設計しようとしています。現時点での私の文法は次のようになります。

Start:
    varDeclarations += XVariableDeclaration*
    rules+=Constraint*;

Constraint:
    {Constraint}
    'FOR' 'PAYLOAD' payload=PAYLOAD 'ELEMENT' element=ID 'CONSTRAINED BY' constraint=XExpression;



PAYLOAD:
    "SimulationSessionEvents"
    |"stacons"
    |"any"
;

値を入力として受け取り、それを制約に含まれる唯一の変数（宣言された唯一の変数でもある）にマップし、制約が満たされているかどうかを確認する、1つのメソッドのみを含むクラスのインスタンスを生成したいと思います。

これらのインスタンスは、別のクラスによって使用されます。別のクラスは、各インスタンスに値を渡し、その制約が満たされているかどうかを確認します。

私が見ているように、私には2つの選択肢があります。

  1. 制約クラスのコードを明示的に生成します。この場合XBaseCompiler、式評価コードを生成するために使用できます。ただし、メモリ内のオブジェクトを直接作成する方法がある場合は、これらのクラスを何らかの方法でロードする必要がありますが、これはエレガントではないようです。

  2. を使用ModelInferrerして、他のクラスに渡すことができるオブジェクトをメモリ内に直接生成するため、クラスをロードする必要はありません。この場合、xbase式の評価コードを生成する方法がわかりません。

すべてのxtextドキュメント/チュートリアルを読み、例を試してみた後、次の質問が残ります。

スケーラビリティの観点から「最良の」アプローチはどれですか（後で文法や彼が生成したクラスの関数を拡張したいと思うかもしれません）？ModelInferrerのアプローチに従うとしたら、どの程度正確に対処できますか？これを行う他の方法はありますか？

どんな助けでも大歓迎です

4

1 に答える 1

2

最善のアプローチは、モデル推論機能を使用してDSL要素のJava表現を作成することです。式は通常、JvmTypeBuilder＃setBodyを使用して割り当てられます。操作本体への割り当てを見つけるドメインモデルの例を見てください。

members += f.toMethod(f.name, f.type) [
    for (p : f.params) {
        parameters += p.toParameter(p.name, p.parameterType)
    }
    body = f.body
]

別のオプションは、コードを手動で作成することです。

body = [
    append(varName).append(' = new ').append(typeName).append('();')
]

型階層、呼び出し階層、またはgo-to-declarationはすべて、派生したJavaのものを尊重するため、推論アプローチは強力なEclipse統合を可能にします。

于 2012-06-28T18:06:23.490 に答える