Tuesday 28 October 2008

The dynamic Future of C# 4.0

P1020889The session I’d been most looking forward to was Anders Hejlsberg’s presentation on the Future of C#. It was clear that many  others were to, because the session room, the second biggest in the convention centre, holding around 2500 people was packed. Anders stood, regarding us all with a Fatherly smile as we filled in. A few dared to approach him. One came forward to get an autograph, and was clearly so overwhelmed that, when the great man asked him for a pen, he forgot that he had one attached to his conference pass, and went back to fetch one from his seat. Others, more brazen, even asked to be photographed with him.

Then the session began. Anders kicked off by outlining the history of C#. You wouldn’t believe it, but it will be Ten years old in December, counting from conception, rather then from birth. C# 1.0 was about managed code; 2.0 was about generics; 3.0 introduced Functional Programming and LINQ. And now 4.0 introduces dynamic programming.

Anders introduced us to the dynamic keyword, which is used when declaring a variable, function return type, or parameter. As Anders said, it is used to declare that the static type of the thing is dynamic. When an variable is marked as being dynamic, C# won’t bother to resolve calls made on that object at compile-time: instead it will delay all method resolution to run time, but will use exactly the same algorithm as it would have used, so that overload resolution works correctly.

The basis of the dynamic resolution is the IDynamicObject interface, shared with the Dynamic Language Runtime. This has on it methods like Invoke which the compiler will call to allow the object itself to participate in method resolution. As well as allowing easy interaction with other dynamic languages such as IronPython and IronRuby this also has the benefit of making COM Interop much more natural. Rather than having to resort to Reflection when encountering “Peter-out typing” (Ander’s term for the phenomenon where COM object models become more loosely typed the further out along a property path you go), using dynamic typing will allow natural-looking code all the way.

Another big help when talking to COM is support for optional and named parameters. Anders made his mea culpa on this one. You can now write code in C# talking to COM the way you could ten years ago in VBA, he said; no longer do we need to call upon Type.Missing to flesh out the method calls to COM objects.

The final thing he announced was support for co-variance and contra-variance of generic interfaces and delegates. No big surprise there: Eric Lippert has been trailing this for a while (hypothetically, of course!). The syntax they’ve decided upon is that type parameters that are only going to be used to return values can be marked with out in the type declaration, whereas parameters that are used for receiving values will be marked with in. For example, IEnumerable<out T>, or IComparable<in T>. I think this is sufficiently complicated to warrant me writing another blog post on it, so that I can understand it better myself.

All in all, no huge surprises, but very useful none-the less. Anders conclusion was that C#4.0 allows you to do things in your code that you were always surprised you couldn’t do before.

But that wasn’t the end. The maestro had one last treat in store for us: a sneak preview of something coming after C# 4.0. Anders explained that for historical reasons not hard to determine, the C# compiler, being the very first C# compiler ever written, is not actually written in C#. This is a big millstone round their collective necks, he admits. So they have already started work on rewriting the compiler in C#, and when it’s done, they will release it for use by the world in its own applications.

It will include the ability to get at a language object model version of code, enabling easy refactoring or meta programming. It could be included in applications to enable runtime evaluation of expressions. To much applause, Anders concluded his session with a demonstration of how easy it is to create a REPL (Run Evaluate Print Loop) using the new C# compiler component.


Post a Comment