Why is an ExpandoObject breaking code that otherwise works just fine?

Question

Here\'s the setup: I have an Open Source project called Massive and I\'m slinging around dynamics as a way of creating SQL on the fly, and dynamic result sets on the fly.

<

Answer 1

It appears that the runtime evaluation of this code is different than compile-time evaluation... which makes no sense.

That's what's going on. If any part of an invocation is dynamic, the entire invocation is dynamic. Passing a dynamic argument to a method causes the entire method to be invoked dynamically. And that makes the return type dynamic, and so on and so on. That's why it works when you pass a string, you're no longer invoking it dynamically.

I don't know specifically why the error occurs, but I guess implicit casts aren't handled automatically. I know there are some other cases of dynamic invocation that behave slightly differently than normal because we hit one of them when doing some of the dynamic POM (page object model) stuff in Orchard CMS. That's an extreme example though, Orchard plugs pretty deeply into dynamic invocation and may simply be doing things that it wasn't designed for.

As for "it makes no sense" -- agree that it is unexpected, and hopefully improved on in future revs. I bet there some some subtle reasons over my head that the language experts could explain on why it doesn't work just automatically.

This is one reason why I like to limit the dynamic parts of the code. If you're calling something that isn't dynamic with a dynamic value but you know what type you expect it to be, explicitly cast it to prevent the invocation from being dynamic. You get back into 'normal land', compile type checking, refactoring, etc. Just box in the dynamic use where you need it, and no more than that.