GetCustomMember: Return Type for Method

May 19, 2009 at 12:22 PM
Edited May 19, 2009 at 3:02 PM

Hi,

The following question may seem odd, but it arises from our currently favored solution to our mixin stable binding requirement (http://dlr.codeplex.com/Thread/View.aspx?ThreadId=53875).

Here goes: What is the expected object to return from SpecialName GetBoundMember/GetCustomMember method, if the requested attribute shall in the end be bound to one of several overloaded methods ?
E.g. if GetCustoMember is invoked on some C# class instance from IPy with argument "Foo" and there are several overloaded Foo-methods, what does one return to be able to call the correct Foo-method as soon as parameters are supplied ?

Currently we are returning a "catch all"-delegate with signature

delegate object ParamsDelegate (params object[] arguments)

This seems to work, apart from two problems:

  1. We cannot deduce the type of null-arguments.
  2. When an array is passed in IPy, it is not passed to the delegate as a single array argument, but instead as if the array members where passed as a seperate argument each (i.e. the argument is treated as a sequence). I know that is the same behavior as in C#, but IMHO the implementation there is already an unfortunate choice.

These make it a less than optimal solution. If we drop the idea that the object returned from GetBoundMember/GetCustomMember shall also be useable from C#, would it then be possible/make sense to return a DLR expression bound to e.g. the different C# Foo methods ?

 

Thanks in advance for any pointers,
Markus

 

 

Coordinator
May 19, 2009 at 4:23 PM

You could use the IronPython object operations class here as a way to get a BuiltinFunction object for your object and then return that.  This would look something like:

private static ScriptEngine _pyEng;

class MyCustomObject {

                private MyProxyObject _obj;

                public object GetBoundMember(string name) {

                                return _pyEng.Operations.GetMember(_obj, name)

                }

}

public MyProxyObject {

                public void Foo(string a) {

                }

                public void Foo(int a, int b) {

}

}

This may or may not work for other languages ObjectOperations classes depending on whether they allow you to get methods as 1st class objects. 

Alternately you would need to return something which implements IDynamicMetaObjectProvider and implement the Invoke fallback and handle the overload resolution yourself – here you’ll get the DynamicMetaObject’s and they’ll have a LimitType == null if the value being passed is null and you could handle your own treatment of how sequences get passed to functions.  This will end up being a pretty big chunk of work though to do all of the method binding and get all of the little details right.  Getting the first 90% right should be fairly easy though.  You could also look at using the OverloadResolver class to assist in this but you might find it’s currently too deeply tied to the ActionBinder to really tease out just the parts you need.

From: MGee [mailto:notifications@codeplex.com]
Sent: Tuesday, May 19, 2009 5:23 AM
To: Dino Viehland
Subject: GetCustomMember: Return Type for Method [dlr:56766]

From: MGee

Hi,

The following question may seem odd, but it arises from our currently favored solution to our mixin stable binding requirement (http://dlr.codeplex.com/Thread/View.aspx?ThreadId=53875).

Here goes: What is the expected object to return from SpecialName GetBoundMember/GetCustomMember method, if the requested attribute shall in the end be bound to one of several overloaded methods ?
E.g. if GetCustoMember is invoked on some C# class instance from IPy with argument "Foo" and there are several overloaded Foo-methods, what does one return to be able to call the correct Foo-method as soon as parameters are supplied ?

Currently we are returning a "catch all"-delegate with signature

delegate object ParamsDelegate (params object[] arguments)

This seems to work, apart from two problems:

1. We cannot deduce the type of null-arguments.

2. When an array is passed in IPy, it is not passed to the delegate as a single array argument, but instead as if the array members where passed as a seperate argument each (i.e. the argument is treated as a sequence). I know that is the same behavior as in C#, but IMHO the implementation there is already an unfortunate choice.

These make it a less than optimal solution. If we drop the idea that the object returned from GetBoundMember/GetCustomMember shall also be useable from C#, would it then be possible/make sense to return a DLR expression bound to e.g. the different C# Foo methods ?

Thanks in advance for any pointers,
Markus

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

May 20, 2009 at 5:47 PM

Hi Dino,

thank you: I just did a test implementation of your suggested solution and it looks like it does exactly what we want, without requiring us to implement our own binding at the same time bypassing the object-array-passed-as-parameter-sequence problem. :-)

Do you know whether other DLR languages apart from IPy will handle things like exposing explicit interface implementations if they are not ambigous the same as IPy does ? This is the question that is still bugging management here (which in turn is bugging me ;-) ), since they do not want to wilfully close the door for support of other DLR languages.

One last thing: Do you have any knowledge regarding the future of Managed JScript you can and would like to share ? I read that rumor has it that it will get the axe, which I find hard to believe. But knowing this to be the case would help us a great deal, since it would make it easier to decide to concentrate solely on IPy (without needing to think about potential compatibility issues).

Thanks again,
Markus

PS: Out of curiosity: Why does IPy handle object arrays like a sequence of parameters instead of as a single array parameter when calling CLR methods ?