Is the dynamic keyword meant to be *only* used with dynamic languages?

Question

I attended Code Camp 12 recently, and a speaker there said that the new dynamic keyword in C# 4.0 should only be used for interopping with dynamic languages. I think he also said that it is somewhat slow, compared to normal reflection (which itself is somewhat slow).

But then I heard Scott Hanselman mention that the dynamic keyword "makes reflection less painful".

So is it going to be acceptable to use the dynamic keyword for the purpose of reflecting an object that doesn't come from dynamic code?

Answer 1

If you feel like you need duck typing and don't really need compile time type safety, go ahead and use dynamic. I'm sure there will be a number of new usages for it popping up in C# only code (such as querying a dynamic data source such as XML using the ExpandoObject). I'm just as sure a large number of the new usages will be superfluous the same way much use of generics is just a more complex way of expressing polymorphism.

Regarding performance, the DLR in .NET 4 is attempting to make dynamic typing "fast". As always, if it's fast enough is something you'll figure out when you start to profile your application.

Answer 2

From what I know, the main reason why the dynamic keyword was introduced in C# was to make it easier to interoperate with COM objects. But of course, it can be used for reflection...

Answer 3

I would have to say, "No". Take a look at http://haacked.com/archive/2009/08/26/method-missing-csharp-4.aspx for an example of a less-expected use.

The dynamic keyword was clearly intended to make COM and dynamic languages much easier to work with, but that doesn't mean we should limit it to those areas. As far as performance goes: keep it in mind, but don't focus on it until you have a performance problem. (This is one of those lower level details that is quite unlikely to affect high level design choices that can cripple performance before you even start.)

Edit

Also, any good language designer is aware of the fact that people will use the language features in unexpected ways. This is particularly relevant for this discussion, because they made an interface that enables the dynamic behavior. They purposefully allowed people to hook pretty much anything into the "dynamic" keywords capabilities.

Answer 4

I would say "no", but don't start using it insanely. Actually, dynamic is, from what I've benchmarked, faster than basic reflection, since it is keeping delegates (rather than using reflection Invoke all the time). In particular, two strengths are:

• calling into generic methods (MakeGenericMethod etc is just so painful)
• calling operators

However, there are using ways of doing what you need with interfaces etc; dynamic on a non-dynamic type really amounts to duck-typing. This is useful in a very limited set of scenarios; mostly: interfaces would be preferred. By don't rule them out.

The downside of dynamic is that to be useful (without writing insane code) you need to know the names at compile-time; which often isn't the case, or we wouldn't be in this pickle! When you only know the name at runtime, there are other options (Expression, Delegate.CreateDelegate, "HyperDescriptor", DynamicMethod, etc) of access the data in a fast way.

Answer 5

Well, the answer is that the dynamic keyword is for interop, but not only for dynamic languages interop. COM interop is just one example. C# team has already modified COM interop to use this feature and this made the interop much easier. I've recently seen that ASP.NET MVC Views are doing something similar.

I have also posted an example that shows another use case for dynamic keyword: Dynamic in C# 4.0: Creating Wrappers with DynamicObject. These are exactly the types of examples Freed was talking about: simplifying interop with XML data.