C# 4.0 introduces a new type: dynamic. dynamic
is a static
type that bypasses static
type checking.
This new type comes in very handy to work with:
Because static
type checking is bypassed, this:
dynamic dynamicValue = GetValue();
dynamicValue.Method();
is equivalent to this:
object objectValue = GetValue();
objectValue
.GetType()
.InvokeMember(
"Method",
BindingFlags.InvokeMethod,
null,
objectValue,
null);
Apart from caching the call site behind the scenes and some dynamic resolution, dynamic
only looks better. Any typing error will only be caught at run time.
In fact, if I'm writing the code, I know the contract of what I'm calling. Wouldn't it be nice to have the compiler do some static
type checking on the interactions with these dynamic
objects?
Imagine that the dynamic
object that I'm retrieving from the GetValue
method, besides the parameterless method Method
also has a string
read-only Property
property. This means that, from the point of view of the code I'm writing, the contract that the dynamic
object returned by GetValue
implements is:
string Property { get; }
void Method();
Since it’s a well defined contract, I could write an interface to represent it:
interface IValue
{
string Property { get; }
void Method();
}
If dynamic
allowed to specify the contract in the form of dynamic
(contract), I could write this:
dynamic(IValue) dynamicValue = GetValue();
dynamicValue.Method();
This doesn't mean that the value returned by GetValue
has to implement the IValue
interface. It just enables the compiler to verify that dynamicValue.Method()
is a valid use of dynamicValue
and dynamicValue.OtherMethod()
isn't.
If the IValue
interface already existed for any other reason, this would be fine. But having a type added to an assembly just for compile time usage doesn't seem right. So, dynamic
could be another type construct. Something like this:
dynamic DValue
{
string Property { get; }
void Method();
}
The code could now be written like this:
DValue dynamicValue = GetValue();
dynamicValue.Method();
The compiler would never generate any IL or metadata for this new type construct. It would only be used, at compile time, for static
checking of dynamic
objects. As a consequence, it makes no sense to have public
accessibility, so it would not be allowed.
Once again, if the IValue
interface (or any other type definition) already exists, it can be used in the dynamic type definition:
dynamic DValue : IValue, IEnumerable, SomeClass
{
string Property { get; }
void Method();
}
Another added benefit would be IntelliSense.
I've been getting mixed reactions to this proposal. What do you think? Would this be useful?