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
give you dynamic behavior with any other DLR-based language.
On Sun, Mar 21, 2010 at 5:53 PM, Paul Felix <paul.eric.fe...@gmail.com>wrote:
> 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]
> public object GetBoundMember(CodeContext codeContext, string name)
> {
> . . .
> }
>
> I make use of the code context to get access to an object that essentially
> represents an application-defined context. I like the idea of being able to
> support other dynamic languages like IronRuby in the future, and I was
> bolstered by the fact that I could implement the special DLR methods with
> Microsoft.Scripting namespaces only (no IronPython namespaces).
>
> But in the newer versions of IronPython, the CodeContext type has been
> moved to an IronPython namespace, thus locking me in to IronPython. To
> remain independent of any dynamic language, am I going to have to implement
> the special DLR methods without the code context and find some other way to
> get at my app object?
>
> Thanks,
> Paul
>
>
> _______________________________________________
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
