Dynamic in C# VI: What dynamic does NOT do

Dynamic in C# Part VI: What Dynamic Does not Do

DotNetKicks.com — Tue, 16 Dec 2008 10:08:40 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: Dynamic in C# VI: What dynamic does NOT do

David M. Kean — Tue, 16 Dec 2008 10:41:57 GMT

The second example is wrong - I think you mean:

dynamic d = new D();

(By-the-way, anonymous comments are disabled)

re: Dynamic in C# VI: What dynamic does NOT do

samng — Tue, 16 Dec 2008 11:44:05 GMT

Whoops, yes you're right, that was supposed to be dynamic.

Anonymous comments are disabled by design.. :)

re: Dynamic in C# VI: What dynamic does NOT do

int19h — Tue, 16 Dec 2008 14:15:43 GMT

> Because of the way the compiler implements explicitly implemented interfaces, C.M gets its name removed (making it uncallable via a C pointer).

Actually, as I understand, it's not really removed - it's still there exactly as spelled, "C.M" - it's just that it's not a valid C# identifier.

That said, it would be useful if we could use arbitrary strings for identifiers in dynamic dispatch (and maybe elsewhere). I.e.:

foo."<bar>"()

or something along these lines.

Of course, this still won't help for explicit interface implementations, as those are also private.

re: Dynamic in C# VI: What dynamic does NOT do

samng — Tue, 16 Dec 2008 21:45:13 GMT

Hey int19h,

I kind of agree with you, though the current thought is that when you've got a statically known receiver, you can guarantee that your arbitrary string will fail at runtime, since your receiver doesn't implement IDynamicObject.

We're currently still in the trenches about the question of how much static time information we should use up front, and what we should delay load. For instance, should we check the arity of the methods? Should we check names? Accessibility? Should we do type inference where possible? How far should we go when we have a dynamic argument, since we know that most likely the call will be dispatched dynamically?

re: Dynamic in C# VI: What dynamic does NOT do

rgoerss — Wed, 17 Dec 2008 14:44:13 GMT

Sam,

What a great entry this is on the current by-design limitations of the DLR; much thanks for sharing your insight.

On the matter of accessibility, I think that it would be valuable to make dynamic code behave in the same way as regular C# code wherever possible, particularly with respect to accessibility and type inference which both lend themselves to intuitive coding.

I think that moving forward it would be preferable to avoid things like....

IEnumerable<object> someObjects = enumerableInstances; // Inexplicably fail for an entire major version of the .NET Framework.

Consider this, for example: A self-contained factory model class has a public, static method that consumes dynamic objects returned by a COM server, instantiates a concrete .NET type and returns a public interface that the .NET type implements. In this scenario, which happens to be something I encounter every day when working with legacy machine control systems, it makes perfect sense for a public, static member to hand off a dynamic object to an instance of itself through a private member or constructor.

Could this scenario be reworked to be compatible with a DLR implementation that does not allow for this type of accessibility with dynamic arguments? Sure, it could. But that would place more of the unboxing and handling of the dynamic instance in the static portion of the type, ostensibly increasing the amount of time spent in a locked/critical state.

Well, at least this is my take on it, but you are the low level CLR expert -- not me. Maybe my concerns/wants are misguided in some way.

Thanks again for the great articles, Sam.

Rob

re: Dynamic in C# VI: What dynamic does NOT do

Gregory Kornblum — Sat, 20 Dec 2008 04:17:48 GMT

I am glad that this article tries to somewhat dispell the thoughts of dynamically typed languages such as P *cough* H *cough* P. I was getting a little worried. First MVC then dynamic, I felt as if we were going back 10 years in time. I'd be perfectly OK with that however I am still in my 30s! Seriously though, thanks for pointing out that dynamic is not much more then an evolved object. Keep up the great work over there!

re: Dynamic in C# VI: What dynamic does NOT do

Pop.Catalin — Tue, 23 Dec 2008 14:18:03 GMT

Please don't introduce inconsistencies in the language. This will make converting from dynamic to static very cumbersome and error phrone. Making use of dynamic to prototype then switch to static types a non valid scenario.

dynamic foo = 1;

foo += ++foo + foo++;

should be evaluated using the same rules the compiler uses to evaluate the next expression with static types (left to right one time evaluation of operands):

int bar = 1;

bar += ++bar + bar++;

Even if it means the CLR team steeping in and adjusting the way the CLR works with boxed primitives (Just like they did with Nullable<T>, and that was a 12th hour change).

re: Dynamic in C# VI: What dynamic does NOT do

EdgarHarris — Wed, 31 Dec 2008 23:29:12 GMT

One of the things that kills me about C++ is the language is incredibly complex. Paraphrasing Scott Myers, there's an exception to every rule, and an exception to most exceptions. While I think supporting inetrop with dynamic languages is an important feature, some of the behaviors you bring up here really concern me. I think that the issue with struct mutation and accessibility really need to be addressed. If these issues are not addressed we could end up with C# evolving into a language that is as complex or nearly as complex as C++.

re: Dynamic in C# VI: What dynamic does NOT do

samng — Fri, 02 Jan 2009 06:45:47 GMT

Whew, sorry I haven't responded to comments in a while! Been on Christmas vacation :)

Okay, lets try to address these:

Rob - Thanks for your kind words! These comments definitely help make it much easier to keep blogging. I appreciate your thoughts!

I entirely agree with you - we've recently taken the design change to make this type of scenario work. Dynamic will now consider the same accessibility rules that the static language considers. This means that each of the callsites will encode their calling context (ie the containing type that the callsite lives in) so that the runtime binder can check the accessibility from the calling context location.

This will then enable the scenario you described, and will give runtime binding errors if the method is not accessible from the calling context location.

Kornblum - thanks for your comments! We are definitely trying very hard to make sure that the designs that we come up with have been vetted with the community, and are trying to take all the feedback that we can!

Pop.Catalin - the scenario you described works identically in both dynamic and static code. The thing that does NOT work is the nested struct scenario. This means that you cannot prototype with dynamic and then convert back to struct - this makes sense, since dynamic is a reference type and structs are value types.

Edgar - as I mentioned above, we're addressing the accessibility issue. I entirely agree with you that these types of differences are bad, and so we're trying to work out all the kinks in the implementation. The nested struct problem is one that we're trying to figure out the philosophy on - since dynamic is a reference type, does it make sense to mutate structs? Combine that with costs and benefits, and you've got the factors that we're considering when making our design decisions.

Thanks for all the great comments guys!

re: Dynamic in C# VI: What dynamic does NOT do

navid_baverd — Mon, 05 Jan 2009 09:54:12 GMT

please examples of class in c# FORWARD in id "Baverd_mohammad@hotmail.com"

Thank you FAR

Community Convergence XLVIII

Charlie Calvert's Community Blog — Wed, 14 Jan 2009 16:25:55 GMT

Welcome to the 48th Community Convergence. The C# team continues to work hard to get out the next version

re: Dynamic in C# VI: What dynamic does NOT do

commongenius — Wed, 14 Jan 2009 20:22:06 GMT

"There is a restriction in the CLR that prevents the compiler from generating non-virtual calls on virtual methods."

This is obviously not true, since "base.ToString()" in C# generates "call instance string [mscorlib]System.Object::ToString()", which is a non-virtual call to a virtual method. Can you clarify what you mean by this?

I would very strongly agree with the previous posters that EVERY effort needs to be made to preserve intuitive behavior in dynamic dispatch, even to the point of limiting the feature if it is necessary to maintain that intuitive behavior. As Edgar said, the last thing we need is for C# to become C++.

re: Dynamic in C# VI: What dynamic does NOT do

commongenius — Wed, 14 Jan 2009 20:45:15 GMT

Regarding explicit interface implementations, listing out the members of System.Int32 shows members named System.IConvertible.ToBoolean, System.IConvertible.ToChar, etc. I am not clear on what you mean when you say "Because of the way the compiler implements explicitly implemented interfaces, C.M gets its name removed." It seems to me that the only thing preventing an explicitly implemented interface member is the fact that it is private, and I have to believe that there is a solution to that problem (although I haven't thought of it yet).

re: Dynamic in C# VI: What dynamic does NOT do

samng — Wed, 04 Feb 2009 09:56:53 GMT

Commongenius:

Great catch! I should clarify that. What I really ought to have said is that the CLR prevents the compiler from generating non-virtual calls on virtual methods from outside the class. Since the runtime binder lives outside of the class that the user is calling a method on, and the delegate that it compiles lives outside the type, we are not allowed to do this.

The same restriction actually holds true for Expression Trees. We had to put in a workaround for the expression tree () => base.Foo() by essentially generating a stub method on the current type that does the base call for you, and then generating the call to that stub method from the expression tree.

This technique works for expression trees, and COULD work for dynamic as well, but since the overload resolution happens at runtime, we would essentially need to generate a stub method for each overload that this occurs in. We therefore decided that this was a fine limitation to live with. However, if we're wrong and people actually feel the need to use this more than we anticipate, we will definitely take a look at the design again in the future!

Re: your second comment:

Again, great catch! I should be more clear when I write... :) You're right that the name doesn't get wiped clean - it gets fully qualified. This means that there is no method named "M" on C, but rather there is a "IFoo.M" on it.

There are two major reasons that require us to keep this limitation though. The first is that explicit interface implementations were meant to be views on the object through an interface view. But at runtime, there are no interfaces, and hence no views. The second (and in my opinion more compelling) reason is that a class may implement several interfaces that have the same overload, and can explicitly implement all of those methods. At that point, which method should we be picking? They all have the same signature, and all have the same name (well, they would be IFoo.M, IBar.M etc). Without the interfaces, there is no way to differentiate between them!