Using dynamic languages with EPiServer Community

So I'm at MS PDC in Los Angeles and yesterday I attended the session on the DLR (Dynamic Language Runtime) which got me thinking on its possibilities in the EPiServer Community framework. Dynamic languages have been around for quite some time, and those who are familiar with a dynamic language know the benefits, and the confusion involved. With a static language you know what you're getting, you know the properties that are part of your object and you know the type they expose.

If you at any time could change the existence of a property or change its type, life becomes confusing. But when you develop a product these days nothing that you deliver to your customers will ever fit perfectly into what they want - hence the Community attribute system (or properties in CMS) was developed. The community attribute system lets us dynamically specify the blueprint of an object but it also gives us some control because we can strongly type each one of our attributes. When we are using a static and predictable language like C# this works well - we can be sure of the type, but still they do not become part of the object in the same way as developers are used to with the statically created properties.

.NET 4.0 will introduce dynamic possibilities in C# by the static type "dynamic". The "dynamic" type will allow you to treat objects that are inheriting DynamicObject with a lot less constraints than you are used to and you could write something like this:

public class Company : DynamicObject
{
// implementation
}

...

dynamic d = new Company();
d.Founded = DateTime.Now;

but it also allows something as horrible as this:

d.Founded = "yesterday";

So how do we get the best out of both worlds? We want to dynamically create new properties on an object, but we would want some kind of type control. Luckily the whole process for implementing a DynamicObject is up to the implementor and the implementation is very similar to the attribute system (basically a collection of name-value pairs). If we would apply the same type control as we have today onto the implementation of DynamicObject, we would get a semi-dynamic object that would result in a far better scenario:

dynamic d = new Company();
d.Founded = DateTime.Now;
d.Founded = "yesterday"; // will throw since the definition expects the type DateTime

Sure, having gotten a compile error before this would have been ideal, but this is the result of merging static with dynamic.