The dynamic keyword was added, together with many other new features of C# 4.0, to make it simpler to talk to code that lives in or comes from other runtimes, that has different APIs.
Take an example.
If you have a COM object, like the Word.Application object, and want to open a document, the method to do that comes with no less than 15 parameters, most of which are optional.
To call this method, you would need something like this (I’m simplifying, this is not actual code):
object missing = System.Reflection.Missing.Value;
object fileName = "C:\\test.docx";
object readOnly = true;
wordApplication.Documents.Open(ref fileName, ref missing, ref readOnly,
ref missing, ref missing, ref missing, ref missing, ref missing,
ref missing, ref missing, ref missing, ref missing, ref missing,
ref missing, ref missing);
Note all those arguments? You need to pass those since C# before version 4.0 did not have a notion of optional arguments. In C# 4.0, COM APIs have been made easier to work with by introducing:
- Optional arguments
- Making
refoptional for COM APIs - Named arguments
The new syntax for the above call would be:
wordApplication.Documents.Open(@"C:\Test.docx", ReadOnly: true);
See how much easier it looks, how much more readable it becomes?
Let’s break that apart:
named argument, can skip the rest
|
v
wordApplication.Documents.Open(@"C:\Test.docx", ReadOnly: true);
^ ^
| |
notice no ref keyword, can pass
actual parameter values instead
The magic is that the C# compiler will now inject the necessary code, and work with new classes in the runtime, to do almost the exact same thing that you did before, but the syntax has been hidden from you, now you can focus on the what, and not so much on the how. Anders Hejlsberg is fond of saying that you have to invoke different “incantations”, which is a sort of pun on the magic of the whole thing, where you typically have to wave your hand(s) and say some magic words in the right order to get a certain type of spell going. The old API way of talking to COM objects was a lot of that, you needed to jump through a lot of hoops in order to coax the compiler to compile the code for you.
Things break down in C# before version 4.0 even more if you try to talk to a COM object that you don’t have an interface or class for, all you have is an IDispatch reference.
If you don’t know what it is, IDispatch is basically reflection for COM objects. With an IDispatch interface you can ask the object “what is the id number for the method known as Save”, and build up arrays of a certain type containing the argument values, and finally call an Invoke method on the IDispatch interface to call the method, passing all the information you’ve managed to scrounge together.
The above Save method could look like this (this is definitely not the right code):
string[] methodNames = new[] { "Open" };
Guid IID = ...
int methodId = wordApplication.GetIDsOfNames(IID, methodNames, methodNames.Length, lcid, dispid);
SafeArray args = new SafeArray(new[] { fileName, missing, missing, .... });
wordApplication.Invoke(methodId, ... args, ...);
All this for just opening a document.
VB had optional arguments and support for most of this out of the box a long time ago, so this C# code:
wordApplication.Documents.Open(@"C:\Test.docx", ReadOnly: true);
is basically just C# catching up to VB in terms of expressiveness, but doing it the right way, by making it extendable, and not just for COM. Of course this is also available for VB.NET or any other language built on top of the .NET runtime.
You can find more information about the IDispatch interface on Wikipedia: IDispatch if you want to read more about it. It’s really gory stuff.
However, what if you wanted to talk to a Python object? There’s a different API for that than the one used for COM objects, and since Python objects are dynamic in nature as well, you need to resort to reflection magic to find the right methods to call, their parameters, etc. but not the .NET reflection, something written for Python, pretty much like the IDispatch code above, just altogether different.
And for Ruby? A different API still.
JavaScript? Same deal, different API for that as well.
The dynamic keyword consists of two things:
- The new keyword in C#,
dynamic - A set of runtime classes that knows how to deal with the different types of objects, that implement a specific API that the
dynamickeyword requires, and maps the calls to the right way of doing things. The API is even documented, so if you have objects that comes from a runtime not covered, you can add it.
The dynamic keyword is not, however, meant to replace any existing .NET-only code. Sure, you can do it, but it was not added for that reason, and the authors of the C# programming language with Anders Hejlsberg in the front, has been most adamant that they still regard C# as a strongly typed language, and will not sacrifice that principle.
This means that although you can write code like this:
dynamic x = 10;
dynamic y = 3.14;
dynamic z = "test";
dynamic k = true;
dynamic l = x + y * z - k;
and have it compile, it was not meant as a sort of magic-lets-figure-out-what-you-meant-at-runtime type of system.
The whole purpose was to make it easier to talk to other types of objects.
There’s plenty of material on the internet about the keyword, proponents, opponents, discussions, rants, praise, etc.
I suggest you start with the following links and then google for more: