Dynamic in C# II: Basics

re: Dynamic in C# II: Basics

Adil Mughal — Sun, 28 Jun 2009 17:24:58 GMT

Excellent! I think I need to go through each post in your blog. Love the stuff. Keep posting.

C# 4, Dynamic Overloads

Mike Taulty's Blog — Fri, 06 Mar 2009 17:13:41 GMT

Another experiment with C# 4 and the “dynamic type”. I was playing with this code below and wasn’t 100%

Dynamic in C# VII: Phantom Method Semantics

Sam Ng's Blog — Thu, 25 Dec 2008 06:44:53 GMT

By now, my hope is that you all have a well-rounded view of dynamic. We started this series by introducing

DYNAMIC IN C# II: BASICS

DotNetKicks.com — Tue, 16 Dec 2008 22:15:13 GMT

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

Dynamic in C# III: A slight twist

Sam Ng's Blog — Tue, 16 Dec 2008 22:13:53 GMT

Last time we dealt with the basics of dynamic binding . This time, we'll add a small twist. First, lets

C# Dynamic - CSharp's new feature of the coming version 4.0

Journal of Abu Sayed Mohammad Ismail — Mon, 15 Dec 2008 21:01:27 GMT

Very good resources for the coming version... Sam Ng Dynamic in C# Part One Dynamic in C# Part Two Chris

re: Dynamic in C# II: Basics

samng — Thu, 06 Nov 2008 02:17:51 GMT

Thats exactly the rationale that we've been using when making these decisions, but yes, I agree with you that this is yet another point in which explicit interface implementations are second-class citizens.

Though, like you say, theres not much we can really do about this one with the current architecture and framework... :)

re: Dynamic in C# II: Basics

int19h — Tue, 04 Nov 2008 22:19:12 GMT

> We may make a call and say that if the receiver is dynamic, you cant call explicit methods on it, but if the receiver is static, then you can.

Given that you seem to be really trying to make runtime resolution as close to compile-time as possible, what you describe seems to be the only sensible approach. It allows for a simple rule of thumb: if receiver is dynamic, overload resolution is exactly the same as if "dynamic" type was replaced by the actual type of the object (and if it's not dynamic, then its declared type is used).

It's just a pity that, if you go that way, it will mark yet another point on which explicit interface implementations are second-class citizens in C# (another, existing, sore point is that you cannot properly override them with the ability to call base implementation in C#, even though CLR allows for that).

re: Dynamic in C# II: Basics

samng — Tue, 04 Nov 2008 21:15:31 GMT

int19h -

Great question! This is one issue that we're currently looking into. The consideration is this:

Explicitily implemented interfaces are (statically) callable only through the interface, and not through the implementing object.

However, at runtime, there really isn't a notion of interfaces - everything is just a bunch of runtime objects. So from a purely legalistic approach, these guys should never be callable.

BUT - and this is a big but, and a bit of a spoiler for my next post - dynamic invocations can happen with a STATIC receiver! What happens if that receiver is the correct interface?

Consider:

IFoo f = ...;

dynamic d = ...;

f.Foo(d);

Because at compile time, the type of d is dynamic (the second class of dispatches in my post), we cant resolve the call to Foo at compile time, and must do it at runtime. But the receiver is known at compile time to be an explicit interface! That means the runtime binder should dispatch to that interface call, because the call itself was never meant to be dynamic!

So what do we do?

We're not sure yet! :) We may make a call and say that if the receiver is dynamic, you cant call explicit methods on it, but if the receiver is static, then you can. I'll definitely let you know more on it when we decide!

But again, great question!

re: Dynamic in C# II: Basics

samng — Tue, 04 Nov 2008 21:15:31 GMT

int19h -

Great question! This is one issue that we're currently looking into. The consideration is this:

Explicitily implemented interfaces are (statically) callable only through the interface, and not through the implementing object.

However, at runtime, there really isn't a notion of interfaces - everything is just a bunch of runtime objects. So from a purely legalistic approach, these guys should never be callable.

BUT - and this is a big but, and a bit of a spoiler for my next post - dynamic invocations can happen with a STATIC receiver! What happens if that receiver is the correct interface?

Consider:

IFoo f = ...;

dynamic d = ...;

f.Foo(d);

So what do we do?

But again, great question!