Microsoft has changed its mind in keeping C# a strongly typed language. All of the virtues of strongly typing your variables, and depending on alternative languages such as Visual Basic for such coding techniques as late binding, are soon to be flushed down the toilet. Since C# is a product and not an open-source language firmly grounded upon disciplines (apparently ECMA is a farce), Microsoft is apparently trying hard to keep the much-loved language evolving according to the demands and requests of its users rather than keep each language feature unique to each language dependent upon its featured language. Late binding was one of the last things that made Visual Basic more versatile to programmers than C#, and it is a feature that Microsoft has finally caved on and decided to add to C#. In the end, where dynamic code is used, there is no member checking on late-bound objects, and code like this is plausible.
static void Main(string[] args)
{
dynamic
{
object myDynamicObject = GetDynamicObject();
myDynamicObject.SomeMethod(); // call a method
myDynamicObject.someString = "value"; // Set a field
myDynamicObject[0] = 25; // Access an indexer
}
}
http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx
The above code, which syntax is not finalized, gives some relief to doubters with its explicit "dynamic { }" block. It suggests that C# will still enforce type safety and member checking at compile-time, except only where late-bound code is invoked in a "dynamic" declaration block.
Microsoft added "strongly typed anonymous typing" in C# 3.0 with the keyword var and with the ability to create and populate anonymous types. I for one thought var was C#'s biggest invitation for bad code abuse, but I was persuaded that "it's okay, it's still strongly typed" because ultimately the type does infer a strong type at compile-time and you get compile-time checking if you use members that are not part of what is assigned.
But late binding invokes no such member checking. Late binding is potentially useful in places where System.Reflection was previously used to perform invocations of type members without having a strong reference to them at compile-time, such as in plug-in support. However, as with var, there is potential for abuse of this functionality; outside of plug-in support, it should not be used at all in my opinion. (But I can just imagine the sort of fist-fighting that was going on between the CLR team and the Microsoft Office COM automation team.)
On the other hand, I can see where this functionality would be necessary for being able to interoperate with objects created in a dynamic language. I hope this will mean that Silverlight v3.0 will natively be able to support interoperating with browser Javascript objects, although that's likely wishful thinking since browser Javascript does not run in the CLR...
EDIT: So um as I was writing this post I was all bent out of shape but then I noticed the dynamic {} block and realized it's okay so but then I left the "bent out of shape" bits at the top so *sigh* .. I hate mondays .. I'm tired ..