I posted some sample code recently, for some tests with C# 4.0 dynamic. Now I’ve found a new interesting thing – perhaps this is also related to using beta 2 instead of the RC, again I’ll try this when I get around to it.

The thing is, I have created my own dynamic object:

public class MyDynamicType : DynamicObject {
  public override bool TryInvokeMember(InvokeMemberBinder binder, 
    object[] args, out object result) {
    Console.WriteLine("TryInvokeMember {0}", binder.Name);

    result = null;
    return true;
  }

  public override bool TryGetMember(GetMemberBinder binder, out object result) {
    Console.WriteLine( "TryGetMember " + binder.Name);
    return base.TryGetMember(binder, out result);
  }
}

Very simple. Now, you already know my little DoFall helper function. I have this code in my main program:

dynamic myObject = new MyDynamicType();
myObject.Fall( );
DoFall(myObject);

Not surprisingly, this is the result:

TryInvokeMember Fall
TryInvokeMember Fall

Now I add my previous tests back into the main method, so I have this code altogether:

DoFall(new Leaf());
DoFall(new ExchangeRate());
DoFall(42);

dynamic myObject = new MyDynamicType();
myObject.Fall( );
DoFall(myObject);

What do you think the result is going to be??? Wrong! Here’s what I get:

Leaf is falling
Exchange rate is falling
Turns out 42 can't fall.
TryInvokeMember Fall
TryGetMember Fall
Turns out Dynamic.MyDynamicType can't fall.

Magic, eh?

For a while there I thought there was some logic in this – after all, Fall could conceivably be an element that has to be “accessed” first, before it can be “executed", like a property that returns an anonymous function or similar. But since the behavior seems to change with the surrounding code in the caller method, it looks much more like a bug… hopefully just in beta 2.

Update: Since this behavior hasn’t changed in VS 2010 RC, I have reported the problem to MS on their Connect Site: Dynamic Dispatch in C# doesn’t seem to work in simple case

I’m testing a few things with VS 2010 beta 2, around the “dynamic” keyword in C# 4.0. Mostly good, but there’s a bit of odd behavior – I thought I’d post about it, in case somebody has a comment, and so I don’t forget to test again once I go to the RC again (had it installed the other day, just to find there was no compatible IronPython release and no F# PowerPack either!).

So here’s one thing that’s weird. I have two classes:

public class Leaf {
  public void Fall( ) {
    Console.WriteLine("Leaf is falling");
  }
}

public class ExchangeRate {
  public Action Fall {
    get {
      return ( ) =>
        Console.WriteLine("Exchange rate is falling");
    }
  }
}

I also have this helper function:

static void DoFall(dynamic thing) {
  try {
    thing.Fall( );
  }
  catch {
    Console.WriteLine("Turns out {0} can't fall.", thing);
  }
}

I call the helper function like this:

DoFall(new Leaf( ));
DoFall(new ExchangeRate( ));
DoFall(42);

The result is the obvious one:

Leaf is falling
Exchange rate is falling
Turns out 42 can't fall.

But now I call the helper function like this instead:

var things = new dynamic[] {
  new Leaf(),
  new ExchangeRate(),
  42
};

foreach (dynamic thing in things)
  DoFall(thing);

And suddenly the result changes:

Turns out Basics.Leaf can't fall.
Exchange rate is falling
Turns out 42 can't fall.

Suddenly, the method Leaf.Fall can’t be executed anymore… funny that, I would have thought that would be the more obvious of the two implementations in this example.

I’ve had a similar difference in behavior before, when I was implementing my own DynamicObject. In that case it came down to different optimizations (?), which the C# compiler apparently applies based on how much it knows about the actual object type at the point of invocation. These resulted in two different call patterns for my own type, where TryInvokeMember would be used in some cases and TryGetMember followed by Invoke in others. I can imagine that something similar is behind this case I’m seeing now, but of course there’s not much I can do about it here, since the types in question are just standard C# classes.

Well. I’ll try again with the RC. Meanwhile, if you have any comments, feel free…

I just felt the need to tweet about how bad the Add References dialog in VS 2010 has become, and somebody actually asks why… well, here’s the stuff I sent to MS a while back (just my part of the conversation, since I don’t have time to go ask for permissions to include theirs), with some comments added for clarity:

What is it with the Add Reference dialog? Somehow you never get this thing right… let’s see:

• At a glance it seems faster than it was, but that’s only because the loading process of the assembly list now happens in the background. In reality it takes just as long as before to load that list, only now there’s no real indication of when the loading is done. This is really a step backwards. (Comment: after working with it for a while, I find this is really a pita. The assembly I’m looking for always seems to be one of those that are not in the list from the start, so I wait and wait, and I never know when the thing is done. Bah.)

• The elements in the list are in some chaotic order once the loading finally finishes. (Comment: … and sorting them while the filling process is still working doesn’t even seem to be possible.)

• You took away the Recent tab, which makes dealing with the dialog even more painful. (Comment: I found out just a moment after sending my email that this problem only comes up for F# projects. Anyway, it’s still the same issue in the RC, it is a loss of functionality compared to VS 2008, it is important, especially in view of the stupid dialog I’m discussing here, and they have no plans to add this back in for VS 2010 final. Great.)

• There are still not even the simplest features in place, like for instance a search box. Yes, I know you don’t have time, etc etc, but that’s a 20 minute feature, don’t you think? (Comment: turns out in the conversation that MS guys don’t think this is a 20 minute feature, thanks very much. Well, go figure.)

I don’t know, guys… I don’t want to blow this up out of proportion, but these simple things are what makes working with the tool pleasurable vs not. You can add as many new WPF based editors as you like, but I won’t be very impressed unless you start addressing simple usability issues like this.

Of course I could easily add things like “why on earth is that dialog so slow to begin with?". Why? I don’t know. Well, the GAC isn’t the most easily readable structure in the world, and VS has its own funny lookup mechanism on top of that, but really… we’re only reading a few hundred entries. I don’t know… this would be something I’d take a profiler to, and I have a hard time believing it really has to be this slow. And if it’s really true - how about caching? Something?

I don’t think I’ve met a single VS developer who doesn’t hate that dialog with a passion. Every time I do a presentation or a training and for some reason I have to bring up that dialog (yes, every trainer/presenter I know tries to optimize their classes/talks so that the thing is never needed!!), there’s a groan or a laugh going through the room, depending on attendees’ moods.

Microsoft. Seriously. Please. Fix that thing!

I was just trying out this piece of code:

dynamic expando = new ExpandoObject( ) {
  FirstName = "Oliver",
  Name = "Sturm"
};

This doesn’t work! Not sure whether that’s intended (this is VS 2010 beta 2, in case you’re wondering), but it really seems like a feature that should work… of course, if you’re not familiar with the ExpandoObject, this piece of code does work:

dynamic expando = new ExpandoObject( );
expando.FirstName = "Oliver";
expando.Name = "Sturm";

Any insights? Or I’ll have to brave the volume of that mailing list…