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
object you return implements both IList and IList<object>. The natural
candidate is List<Object>.
On Mon, Mar 22, 2010 at 7:08 AM, Paul Felix <paul.eric.fe...@gmail.com>wrote:
> 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 could I perform a language-specific conversion?
>
> In other words, with my scriptable application, I might want to better
> support the scriptwriter's language by returning language-specific types. If
> a scriptwriter is using Python, it would be nice to return a Python list for
> SomeMember. If the scriptwriter is using Ruby, it would be nice to return a
> Ruby list.
>
> If there was some way to get access to a type converter based on the
> "calling context", this might be doable.
>
> Does that make sense?
>
>
> On Sun, Mar 21, 2010 at 8: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
