C# 3.0

[jducoeur]

For programming junkies only: now that C# 2.0 is on the verge of becoming real (in late beta, with real release coming in a couple of months), they're starting to talk brass tacks about the 3.0 version of the language. It's fairly ambitious, although not everything I might wish. Info can be found at the C# Future Versions page.

Major things I notice in the preliminary language spec:

• They're starting to pick up serious elements of functional programming. (The C language family finally moves into the 1990s.) 2.0 gets anonymous methods; 3.0 gets lambda expressions. They're adding type inference, which is almost audacious for a C-family language, although this version still seems pretty simplistic compared to more serious functional languages. (Actually, I think the main point of the type inference is to simplify the syntax of the lambda expressions, and move a bit closer to higher-order functions.)


• New, intriguing concept called "extension methods", which allows class A to declare extensions to class B. Not really a true mix-in capability, but an interesting bit of syntactic sugar.


• Proper object member initializers, fixing a lack that's been conspicuous since 1.0. (They've always had initializers for attributes, but not for real objects; the discrepancy has always struck me as strange.)


• "Anonymous types", which are essentially strongly-typed property bags -- you initialize an object with a bunch of properties, and a new type is created based on those properties. Similarly, implicitly typed arrays, which infer the array type based on the initialized contents.


• A Query language, rather similar to SQL, built into the C# language. It's not specifically DB-based, although it's clearly optimized for that. The notion is basically that, if you have a collection that conforms to the queryable interface, you get a bunch of syntactic sugar for managing those queries.

Overall, it's not bad. I like the functional enhancements -- I'll be very curious to see whether they cohere well enough to make C# behave like a higher-order language. The Query language looks potentially interesting, but seems like a half-measure compared to the stuff in Comega; I'm disappointed that they don't seem to be going whole-hog with the streams concept in there.

In sum, I'll look forward to it. (But not as much as to the generics that I'm about to get...)

Comments

[jducoeur]

Note to myself: the more I look at Extension Methods, the more they look like mix-ins. You can declare an extension based on a template, which can be based on an interface, so you can essentially mix new capabilities into, eg, all IEnumerables. Used properly, that's actually pretty powerful...

[learnedax.livejournal.com]

Actually, looking at the spec I think Extension Methods have certain similarities with mix-ins, but are quite distinct. Let us say that in an expression like foo.bar(), foo is an instance of A, bar() is defined in B, and the expression is evaluated within the context of C. Mix-ins are a way of giving A control of delegating to B, and Extension Methods are a way of giving that control to C. I see that difference as very important, because mix-ins are an OO tool used for sneaking in multiple inheritance, which you don't seem to be able to do at all with EMs. Rather, they offer lexically-scoped universal methods.

Coming from a different background, this looks to me a lot like parts of perl's AUTOLOAD system. In a number of ways this is more cleanly implemented, since it has built in both lexical scoping and multiple dispatch fall-through, which could mean a lot less fiddling. (Although, as with mix-ins this does raise some tricky cases of inheritance, particularly given precedence and multiple dispatch rules.) On the other hand, there are some design quirks I'm dubious about, e.g. importing EMs by namespace but defining them by object - if all static methods from all objects within a namespace are dumped together, it doesn't really make sense to put them in classes. They're doing a thing that works procedurally, but they're making the definition conform to OO syntax, which strikes me as a little kludgy.

Overall I'd say they seem to be moving C# closer to the neighbourhood of perl and ruby, but it remains to be seen where it will end up.

[jducoeur]

I concur that functionally Extension Methods are quite different from mix-ins. But it seems to me that I'm likely to use them in somewhat similar ways, which is why they are feeling somewhat similar to me. The nuances are quite different, but the broad scope is related.

And I concur that having the EMs lumped into classes is a tad kludgy. But now that I'm understanding the basis better, I'm not wholly surprised. Like everything else in C# 3.0, they're really there to support the LINQ project, so they're tolerating a bit of kludginess in the name of getting the necessary functionality with minimal changes to the core language. This *may* come back to bite them in the ass later; we'll see...