In the video, Sam and Chris point out that this:

   dynamic foo = ...;

   object bar = 7;

   foo.Method(bar);

will successfully be bound to an overload of foo that takes Int32 as an argument. I have to admit, I found this surprising, because I expected the binding to occur based on the static typing of the argument.

Just as I was getting used to the idea, based on my expectation that in dynamic languages, overload resolution is probably done based on the actual type of the argument, not the static typing (is this right? I don't actually know Python, etc. so it's just an assumption on my part), they then go on to point out that they accomplish the C# binder implementation by leveraging the existing compiler implementation, reusing it to accomplish the same binding semantics that would exist in the language.

But of course, the language only can resolve overloads based on static typing.  So I'm confused by what they meant in terms of reusing the existing compiler code.

The _behavior_ all makes sense to me, if I make certain assumptions about how dynamic languages work, but I'm confused by how behavior based on static typing is then leveraged for dynamic method invocations.

Or did I misunderstand what was said in the video?

I'll probably use the dynamic feature and contra/covariance, but the rest is beyond what I usually do. It's great to know static and dynamic worlds are truly combined. I can't wait to call DirectShow objects with automatic interoping. Am I right? Will that work? I'd love to see a DirectShow example...

@peted,

While static and dynamic binding use the same implementation to resolve overloads, they are done at different times - compile time and runtime. At runtime, runtime types are known and the line foo.Method(bar) is resolved as FooType.Method(int).

When Sam Ng was explaining dynamic method binding, he had a piece of code something like this:

dynamic d = ____

object[] array = new [] { 1, "s", new ( C ), 10 };

foreach (object o in array)

{

   d.Foo(o);

}

He explained that when o holds one of the integers 1 and 10 then Foo in d.Foo(o) will bind to the method Foo _that takes an integer_ on the runtime type of d. But why would you bind a method that takes an integer when you're supplying it with an expression that is statically of type 'object'? It makes more sense only try to bind it to a method Foo that takes an object. I would naively expect that there is a necessity to declare o as dynamic (instead of statically typed as object) for the semantics to care about what the run time type of o is.

Oh dear, I just realised I was talking about the same thing peted was. I should read better before I post; sorry for that.

Welcome to the 47th Community Convergence. We had a very successful trip to PDC this year. In this post

@configurator:

Yes, I understand the stated behavior.  But I don't understand yet why that stated behavior is consistent with a) using the same compiler code, and b) what's been said elsewhere about how this stuff works.

As another example, check out Sam Ng's latest blog post:

http://blogs.msdn.com/samng/archive/2008/11/09/dynamic-in-c-iii-a-slight-twist.aspx

In it, he writes "dynamic binding behaves exactly as it would at static compile time, with the exception that the type used in place of the dynamic objects (arguments or receiver) is the runtime determined type instead of the compile time determined one. This means that for all arguments not statically typed dynamic, the compile time types will be used, regardless of their runtime types"

Taking that statement at face value, I would expect our example above to call the Method(object) overload, not the Method(Int32) overload.  After all, the only thing the "dynamic" type should introduce is run-time determination of the method group to use; the overload resolution should be done based on the static typing of the argument, which is "object".

Basically, I feel like we're seeing contradictory statements regarding the expected behavior of overload resolution with dynamic types.  While I feel like the "use all static information available" approach is the most predictable and least surprising, I wouldn't object to using run-time type information even for elements that have known compile-time type information if that's what the C# designers feel is the best approach.

But right now I think I'm being told two mutually exclusive behaviors will both be implemented.  That's logically impossible, and I'd like someone to straighten me out.  :)

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