Why is ReturnType sealed

Oct 9, 2009 at 11:32 AM

Hello,

What is the reason for SetIndexBinder::ReturnType to be sealed and always return object type ?

There are common scenarious where callsite is expecting void but with SetIndexBinder there is no way how to set ReturnType to be void. Therefore the void expression has to be wrapped into a block which returns a transparent value even if callsite knows the value will be destroyed. The same limitation also applies to InvokeBinder.

Coordinator
Oct 9, 2009 at 7:09 PM

The main reason for having a fixed return type was that we wanted to avoid having the DLR inject conversions and we wanted to keep the model simple. 

Having the value sometime be void and sometime object would mean that all implementations would need to check the return type and inject any appropriate conversions.  It’d also mean you’d get worse sharing amongst rules as void returning call sites would need to have their own cache independent from non-void returning call sites.  Also if we unsealed it then presumably there could be types other than object/void.  In that case you’d complicate cross-language interop because you’d want the binder to perform the conversion and not the dynamic object which is being talked to.  For example getting a member from a Python object from C# and returning int should let C# do the conversion to int.  Requiring the value to always be object keeps things simple and explicit and requires the consuming language to inject a conversion node if one is needed.

If you have a really compelling reason for returning void here then you could always create a custom binder which calls the appropriate Bind method for foreign IDOs but returns void for your own IDOs or for normal .NET objects.  But I’d be surprised if loading null and returning it resulted in any significant problems.

From: marek_safar [mailto:notifications@codeplex.com]
Sent: Friday, October 09, 2009 3:32 AM
To: Dino Viehland
Subject: Why is ReturnType sealed [dlr:71477]

From: marek_safar

Hello,

What is the reason for SetIndexBinder::ReturnType to be sealed and always return object type ?

There are common scenarious where callsite is expecting void but with SetIndexBinder there is no way how to set ReturnType to be void. Therefore the void expression has to be wrapped into a block which returns a transparent value even if callsite knows the value will be destroyed. The same limitation also applies to InvokeBinder.

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

Oct 12, 2009 at 8:32 PM

It seems to me strange to ignore void return type. Is the void cross language compatibility behavior defined somewhere or should I be ready to receive any type/value from a call which is supposed to return void ?

Oct 14, 2009 at 10:47 PM

> It seems to me strange to ignore void return type. Is the void cross language compatibility behavior defined somewhere or should I be ready to receive any type/value from a call which is supposed to return void ?

It’s always safe to ignore the return value. It’s there for languages where a call always result in a value (e.g. Ruby).

- John Messerly