XML Generics

 

Designing a programming language is like inventing a metaphor for thought.  Most of the time you struggle to find just the right metaphor, hoping the one you eventually choose will be the best at communicating the idea it is meant to represent.  So you can imagine the process of language design leaves a lot of dead ideas on the floor as it refines itself toward the ultimate goal of intuitive expression.  This can happen for many reasons, but often it turns out to be just that some representations are better than others due to the way they evoke immediate recognition, understanding and emotional attachment.  Often the best representations have nothing to do with logic or consistency.  Sometimes they are just better.

 

That's why we got so much immediate flak internally when we first introduced XML Generics. It was hard to understand the logic in them, but the emotional draw was undeniable.  They just seemed to be the right thing.  It's not that we did not care to hear the feedback from others, it was just that we knew going in that those closest to us were too tainted/attached to the current design.  Developers and most other logically minded folk have a difficult time detaching from what they know, stepping back and taking in the bigger picture.  And believe me the design for XML generics was going to be a big change, one that would be very difficult to understand without a deep appreciation for where we were going with the language.

 

Likewise, it was anticipated that many in the blogging community would have a similar reaction, so we decided early on that we would need to reach out to the community directly, explain our approach, and gather what feedback we could before launching into a full scale marketing push on the unification of XML and Generics.

 

Some of the more touchy-feely readers out there might start to see it already.  The intuitive leap needed to bridge the two ideas together is one that must be made emotionally not logically.  On the surface, the two might seem to have nothing to do with each other, but if you dig deeper you soon realize that the two are fundamentally linked, both concepts actually compliments of one another.

 

To bring the rest of you up to speed, let’s first take a look at generics, a new feature in C# 2.0 that allows you to define parameterized types. A generic type is defined using the syntax below.  The name ‘T’ refers to the type that parameterizes Foo.  Generic types can have one or more parameters that are substituted on use with actual types.

 

public class Foo<T> { … }

 

When you refer to a generic type, you do so in a similar way, replacing the parameter with the type you would like to use instead, such as in the variable declaration below.

 

Foo<int> x;

 

As anyone can clearly see generic types have a striking resemblance to XML.  Both represent parameterized data.  Both are descriptive and declarative.

 

<Foo x=”…” />

 

We realized intuitively that a greater generalization could exist that tied the two together.  Since this is a quality we strive for when designing the language we knew we were on to something if we just could find the right metaphor to bring the two together in the syntax.   

 

And that’s when it hit me.  The solution was right there, obvious all along.  As it turns out, it was the reason that the whole thing was intuitive in the first place.  It was the brackets, the angle-brackets.  They were the key. So you can understand how the syntax had to change, to evolve, to make the two into one.

 

Foo<int x = “…” />

 

It was beautiful.

 

That’s why I’m so annoyed that it got dropped for something better.  I mean really, do you think pure genius like this grows on trees?

 

But I digress

 

Matt

 

This post rated: AH - Attempt at Humor