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>.<br>
<br>
<div class="gmail_quote">On Mon, Mar 22, 2010 at 7:08 AM, Paul Felix <span dir="ltr"><<a href="mailto:paul.eric.felix@gmail.com">paul.eric.felix@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Thanks, Tomas and Curt. I see your blogs on this topic.<br><br>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?<br>
<br>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.<br>
<br>If there was some way to get access to a type converter based on the "calling context", this might be doable.<br><br>Does that make sense?
<div>
<div></div>
<div class="h5"><br><br>
<div class="gmail_quote">On Sun, Mar 21, 2010 at 8:53 PM, Paul Felix <span dir="ltr"><<a href="mailto:paul.eric.felix@gmail.com" target="_blank">paul.eric.felix@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hi,<br><br>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:<br>
<br> [System.Runtime.
<div>CompilerServices.SpecialName]<br> public object GetBoundMember(CodeContext codeContext, string name)<br> {<br> . . .<br> }<br><br>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).<br>
<br>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?<br>
<br>Thanks,<br><font color="#888888">Paul<br><br></font></div></blockquote></div><br></div></div><br>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.ironpython.com">Users@lists.ironpython.com</a><br>
<a href="http://lists.ironpython.com/listinfo.cgi/users-ironpython.com" target="_blank">http://lists.ironpython.com/listinfo.cgi/users-ironpython.com</a><br><br></blockquote></div><br>