The only shared type system that exists in DLRland is the CLR type system.
Individual DLR-based languages are free to define their types with the
semantics similar to "list" (or "dictionary" or any other type). I think the
most general thing you can do in a case like this is to make sure that the
o
Thanks, Tomas and Curt. I see your blogs on this topic.
Let's say I wanted to use the DynamicObject approach, and I have a dynamic
C# object with a runtime member called SomeMember. Let's say SomeMember is a
.NET List, but I want the object to return a calling-language-specific list
type. How coul
The proper "DLRish" way to make a C# class "dynamic" is to implement
IDynamicMetaObjectProvider. The easiest way to do so for most purposes is to
derive from DynamicObject. GetBoundMember is purely an IronPython mechanism.
Indeed, anything that uses CodeContext is purely IronPython and will not
giv
21, 2010 5:54 PM
To: users@lists.ironpython.com
Subject: [IronPython] CodeContext went from language-independent to
IronPython-specific
Hi,
I am embedding IronPython in an application for scripting. I'm also making some
C# classes "dynamic" by implementing the special DLR methods
Hi,
I am embedding IronPython in an application for scripting. I'm also making
some C# classes "dynamic" by implementing the special DLR methods like
GetBoundMember. My signatures for those special methods include the code
context:
[System.Runtime.
CompilerServices.SpecialName]
pu