Lambda the Ultimate

Don Box and Chris Anderson were presenting C# Generics today as a way of extending non-inheritable value types - for instance, the class Nullable<T> could be used to create ints and floats with a boolean IsNull() method, for use when returning values from SQL database queries. I found it interesting that generics with value types are expanded and those with reference types aren't - and that both are IL features handled at run-time rather than compile-time - quite different in practice to C++ templates.

Don and Chris also demoed iterators and anonymous delegates - that's lazy evaluation (via yield) and lambda expressions, y'all. Not a vast amount of interest in these from most of those in attendance, I have to say - at least one MS guy I spoke to thought they would just lead to code that was more difficult to read. (And that it was a good thing that they were confined to C#, as they would surely cause VB.Net developers to suffer unpleasant brain-seizures).

One more language/IDE feature demoed was "expansions", a kind of macro system based on XML. There was also a lot of XAML; one thing that came across there was that XAML was quite a neat way of avoiding creating a lot of auto-generated imperative code of the

ListBox ListBox1 = new ListBox();
this.Controls.Add(ListBox1);

I am having trouble without a rationale for this new feature. From what I've seen of XAML and other uses of partial classes, the effect could have been achieved with composition and/or inheritance, thus avoiding yet another language feature.

I'm sure I am missing something, and so I am hoping there is a "rationale" document somewhere that will lay it all out.

The XAML file and the "code-behind" file are typically separate, so a mechanism is needed to weave them together. If each were compiled into a separate class, then composition or inheritance could be used to combine the two. Partial classes allow the two files to be compiled together into a single class. Is this necessary? No, but it might be "better" in some ways (at the cost of adding another language feature).

If inheritance were used, then the XAML-derived class (which would presumably have to be the base class, itself inheriting from System.Windows.Forms.Form) could be inherited by several different "code-behind" classes, possibly specifying different behaviours for the same interface. This can be done with partial classes too; the main difference would be that the woven partial classes would be covariant with System.Windows.Forms.Form and not with the XAML-derived base class - they could be treated as equivalent only insofar as both were forms, and the fact that both had the same UI components would be hidden from the class hierarchy. In general, I'm not sure that the relationship between different sets of handlers for the same UI components is the kind of relationship (IS-A) that should be modelled with inheritance, so this seems to me to be a good thing.

I don't know what the case would be against composition. It would surely be simple enough to have an instance of the XAML-derived class as a private member of an "outer" class which provided event-handlers for it. The only objection I can imagine is that this would mean that you had to have twice as many classes as before - instead of having one class per form, you would need both the XAML-derived class and the "outer" class each time. Is an extra language feature worth it?

The real reason, I strongly suspect, is that weaving partial classes together is more like the way ASP.Net works, and makes XAML interface coding and web interface coding look more like each other. Don mentioned that his website is now served as XAML internally within Microsoft, where presumably it's rendered as a XAML document within the Longhorn browser/explorer. So XAML is meant to "stand alone" (within the context of a suitable browser) as well as provide a UI design markup for applications. XAML over HTTP rendered in Longhorn = the Microsoft web. Now doesn't that thought warm the heart of your cockles?