More on Dynamic Support in C#

Posted by Jonathan Allen on Apr 23, 2009

Sections

Architecture & Design,

Development

Topics

C# ,

.NET Languages ,

Dynamic Languages ,

.NET ,

Languages ,

Language Design ,

Programming

Share |

RELATED Research

Mads Torgersen presents more details on the dynamic keyword in C# and how it came to be. Included are some of the alternate designs that were eventually discarded in favor of the dynamic keyword.

C# 4 will be adding support for late binding through the new meta-type “dynamic”. Any variables declared directly as this type, or returned from a function as this type, will automatically be treated as late-bound. This is similar to variables declared as “object” in Visual Basic, but it will support any type system, not just CTS (common type specification) and COM.

An important point is that the goal of this feature is to support late binding, more recently referred to as dynamic binding. Dynamic typing is explicitly not a feature of C#, but rather a consequence of supporting dynamic binding.

It is important to note that reflection is not a viable alternative to this. The problem with reflection is that there are many different kinds. The way you call a method using the Refection namespace is different from the way you call a method on a ScriptObject. And Ruby/Python methods have a third method.

One option was prefixing dynamic operations with a tilde. Unfortunately this quickly becomes unwieldy, especially where you start looking at type casts, array indexes, and mathematical operators

  object d = GetDynamicObject(); string result = ~(string) d ~[ d~.Length ~- 1]; 

The next option considered was dynamic contexts. Like unsafe and unchecked contexts, you could label an arbitrary block of code as “dynamic”. The problem with this is that it makes it hard to mix static and dynamic code. This would have looked like:

  dynamic {
      //some dynamic code
      static {
          //some statically bound code
          dynamic {
              //some dynamic code in some static code
          }
          //some more statically bound code
      }
      //some more dynamic code
  }

Up third was contagious expressions. With this the dynamic nature of an expression would be propagated upwards.

  object d = GetDynamicObject();
  string result = (string) d[ dynamic(d).Length - 1];

Of course the syntax they choose isn’t perfect either. While it makes it easy to read the code, there is nothing to indicate that a dynamic call is being made at the actual call site. That information is only available where the variable is declared.

  dynamic d = GetDynamicObject();
  string result = (string) d[d.Length - 1];

One of the key points that made them settle on this design is that the code isn’t really less safe. Making the dynamic call itself is just as likely to throw an exception as before, but now you don’t have to write all the bloated, error-prone reflection logic.

Another option considered was making dynamic a modifier instead of a meta-type. With the pattern show below, developers could early-bind on Foo’s methods, but late-bind on anything else. While this could have improved performance in edge cases, it adds an overall level of complexity they were not comfortable with.

  dynamic Foo d = GetDynamicFooObject();

Whenever there is a dynamic component to an expression, the whole expression will probably be dynamic. These include

• Method calls
• Invocations
• Member access
• Operator application
• Indexing

The exceptions are fairly obvious; conversions and constructors will return you to a static context. While conversions can be overloaded by DLR type systems, the DLR mandates the result of a conversion is the appropriate type.