But, why not tell the compiler what I expect, beforehand, and then have a "typed" object, where I can use intellisense, even if the final validation is only done at run-time? In my view, I want to create an object with some properties or methods at run-time, or I know "something" about the objects, but the compiler doesn't. I am only saying it is not the exact type of dynamic I expected. I am not saying the dynamic keyword is bad. If you cast a dynamic to " object", to then cast it to another type, even if the dynamic object supports such a cast, an exception will be thrown, because if the compiler does not see the object as dynamic, it will not use its dynamic capabilities. The compiler must see the object as "dynamic" to generate a completely different code.
The dynamic keyword makes everything almost transparent. In my opinion, a dynamic object is an object to act as another object transparently. But I consider that a completely different type of dynamic. Today, we have the dynamic keyword in C#, allowing for real dynamic code.
#Duck typing code#
NET, my first version of Remoting used a C# generated code that I compiled using CodeDOM, at run-time.NET and Today's Dynamic
I must admit that for a long time I used code generators, I generated classes to access my database in a typed manner (using C++), in my final project at university (to create a Delphi Server Pages) and, even in.
If you could simply generate and compile such code at run-time, it is already dynamic. They are the first step to dynamic objects, as the code will be generated from some type of information you already have, like, for example, a database. I think anyone who programs for a long time starts to create "code-generators". 4 th November, 2010: Added support for generic-method definitions and automatic casts for ref and out parameters of different types Background