Re: [IronPython] CodeContext went from language-independent to IronPython-specific

2010-03-22 Thread Curt Hagenlocher
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

Re: [IronPython] CodeContext went from language-independent to IronPython-specific

2010-03-22 Thread Paul Felix
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

Re: [IronPython] CodeContext went from language-independent to IronPython-specific

2010-03-21 Thread Curt Hagenlocher
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

Re: [IronPython] CodeContext went from language-independent to IronPython-specific

2010-03-21 Thread Tomas Matousek
Could you be specific about your scenario? What exactly is an "application-defined context" and the classes that would need an access such object? Tomas From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Paul Felix Sent: Sunday, March 21, 2010 5:5