0

現在、DLR 言語の実装に問題があり、その言語で定義されたメソッドへの後続の呼び出しが、そのメソッドの最初の呼び出しで使用されたのと同じ入力パラメーターで発生します。

だから...私の言語でこれを行うと：

PrintType( 34 );
PrintType( 34.1 );

...出力は次のとおりです。

整数

整数

私が期待する場所：

整数

小数

この問題は、次のことが原因であると思われます (ただし、まだ確認できていません)。

  1. 私のコール バインダー (InvokeAction サブクラス) は、適切な Cal​​l Expression を生成し、その式と Restrictions.Empty を含む新しい MetaObject を返します。

  2. したがって、Restrictions パラメーターは、このコンストラクトがこのメソッドの後続の呼び出しでいつ再利用できるかを DLR に通知し、固有の制限を設けていないため、最初のコンストラクトが常に再利用される (申し訳ありませんが、ここでの私の用語はおそらく間違っています...うまくいけば、あなたはその考えを理解するでしょう）

だから...私は、各パラメーターに対して生成された制限のマージを使用する必要があると考えています...タイプごと、またはおそらくインスタンスごとに。

誰かが私の考えを肯定または否定できますか? 私が見ている動作について、私が探求すべき他の可能性はありますか?

ティア...

4

1 に答える 1

1

あなたの考えは正しいです。この場合、タイプ制限が必要になります。一般に、コードをできるだけ多くの呼び出しサイトから共有できるように、制限をできるだけ少なくする必要があります。

これが機能する方法は、バインダーにルールを要求する前に、DLRがキャッシュされたルールを検索することです。制限は、キャッシュされたルールを新しい入力セットに適用できないようにするものです。

于 2008-12-19T17:37:58.190 に答える