dynamicとその言語への貢献について読みました。dynamicDLR は、リフレクション メカニズムを使用して、オブジェクト ( ) のメンバーへの呼び出しを管理します。しかし、DyamicObject型の動作が (内部的に) 理解できません。
DynamicObjectから継承すると、既存のExpandoObjectのようなものを作成できる可能性があり、 TrySetMember、TryGetMember、およびその他のメソッドを上書きする必要があります。私の質問は次のとおりです。object.methodを実行すると、これがクラスのTryGetMemberにどのように渡されますか?
コメントで明確化された質問への回答。
確かではありませんが、TryInvokeMember などの関数は、リフレクションの基本的な設計上の問題を克服するために、リフレクションを単にラッパーしているだけだと思います。それは、TargetInvocationException という 1 つのタイプの例外のみをスローします。呼び出しているメソッドからの独自の例外を含む他のすべての例外は、TargetInvocationException でラップされます。
動的変数にはその問題はありません。最初にスローされたものとまったく同じ例外をスローします。内部でリフレクションを使用している場合もありますが、根本的な例外をアンラップする必要があります。そして、これが TryInvokeMember と関連メソッドの目的だと思います。また、CLR の開発者は、存在しないメンバーの呼び出しをより適切かつ特別な方法で処理できるようになりました。