Introduction to C# 3

Introduction

Just look at the C# 3 future, it's so pretty I want it now. Check out the videos that they have there. There is so much good stuff there, and it's only the start. First of all, read the C# 3.0 spec [doc file], or just read the rest of the post to see the highlights.

Type Inferencing and Implicitly Typed Arrays

I got addicted to that when using Boo, it's something so simple, but it saves so much. In most cases, it means no more casting hell. Andres let it slip in a presentation about a year ago, in essence, it means:

This is a very cool idea, especially since you can use it for the foreach construct, which should make for far better code. Did you notice how I declared the array? new [], without a type, the compiler just fixed it up automatically.

Extensions Methods

This is a feature that lets you add new instance methods to a class, without touching the class code and even if the class is already compiled. The idea opens up so many possibilities that it's just staggering. Fowler talked about it in Refactoring. Other languages, such as SmallTalk and Ruby already have it (SmallTalk has it for 30 years, I think), and it has proved to be a useful feature. You could add methods to System.Object, which would then be "inherited" by any object. Consider adding ToXmlString() for all objects, for instance. Or persistence to database. And no, it's not just syntactic sugar, those things are important. This mean that you're no longer at the mercy of the class designer. It's a truly powerful tool. The nicest thing about it, I think, is that it'll work with generics, so you get a host of goodness for very little effort. Here is the example from the spec:

What does the above say? Well, it means that you can now use Select() on any object that implements IEnumerable. You could even use them on your 1.0 and1.1 collections! Can you say goodness? This is cool on so many levels that it's not even funny.

Extension properties, events and operators are currently considered, but not yet supported. I certainly hope that Microsoft will implement those, as they would allow a much nicer syntax for a lot of things (an IsNull property, for a start). Adding operators to interfaces is another big problem that this can solve.

Lambda Expressions

This is like anonymous methods, only with an even easier syntax. This is something that I don't think most .NET developers will appreciate now, but they certainly would two years from now, when the functional goodness will be fully entranced. Here is how you would extract all the names from a list of customers:

string[] names = GetListOfCustomers().Select( c => c.Name );

Can you see the beauty of it? The "c => c.Name" is the lambda expression, which is just a way to tell the compiler to do the dirty work, instead of having to do it ourselves using anonymous delegates. If it was all that they were good for, they wouldn't amount to much, but they have quite a few other usages, as you'll see shortly.

Object and Collection Initializers

This is something that we had for quite some time in attributes, which is now coming to both object initialization and collections initialization. The idea is actually very simple, consider the class Person:

This would create a new type with Name and WebSite properties. While this may save some typing in certain cases, I'm not certain that this is a useful feature. You cannot use it outside of a method's boundary, since it has no type that you can access.

This is nice, but I don't like the way it's implemented now. Boo has something similar, but since Boo has type inferencing throughout the language there it actually makes sense, since it allows to return a strongly typed object from a method, instead of an object array. Here is the Boo example:

Since declaring variables using the var syntax is limited to local variables, I think this is unnecessarily limited.

Query Expressions

I expect this to be the big thing for C# 3, just as generics are the big thing for C# 2. The idea is to allow an SQL like syntax for selecting objects from a database/memory/XML directly into the language. The idea is quite involved, and I'm sure it will generate a lot of discussion. The idea is to be able to do the following:

There are all sorts of ways where you can plug into this statement and do all sorts of cool things with it. db.Customers may be an in memory class, or it can redirect the query to database, to remote machine, etc. This is also apparently the use case for anonymous types, as return types from lambda expressions. It's nice, but it's not enough. It should be expanded to regular methods as well, in my opinion. I suggest checking the spec anyway, I'm just touching the edge here, and I'm sure that there are a lot of cool implementations that I'm missing here.

Expression Trees

They are a way to turn lambda expressions into data. The idea is to be able to do this:

var valuedCustomers = session.Select(x => x.IsValued==true);

What is this? Well, what happened here is that we saved the lambda expression "x => x.IsValued==true" and passed it to a persistence layer, which would parse the expression, and load from the database all the rows for which the expression is true.

The important thing here is that the Select method is not using a opaque string, but code that can be type checked and verified by the compiler. Presumably refactoring tools for C# 3 will also support this, so it will make life even easier.

For the author of the Select() method, life would be much easier as well. He won't have to parse strings, but rather deal with an AST tree. From experience, I know that dealing with ASTs is not the easiest thing in the world, but it's certainly much better than dealing with strings.

Summary

All in all, I really like the direction that C# 3 is heading for. Functional programming is not appropriate all the time, but it can save quite a bit of typing and a lot of awkward syntax. I'm very excited about the new abilities, and I think that they will present a quantum leap much bigger than 1.1 -> 2.0. Considering that those are just the language enhancements, I can hardly grasp the amount of goodness we will get in the class library and the associated tools.

I expect quite a lot of noise about query expressions (yes, they are cool). And a lot of activity in the area of lambda expressions as data, since it's a cool way to express much more than just ORM syntax.

Atually var is needed for the LINQ query operators. It's pretty unreadable to work with explicitly typed variables in the case where the LINQ queries get more complex. Also if you change one thing in the query, you most probably need a small change to the type declaration for the variable that is holding the result.

I really hope noone is going to use var for all those utility variables. That would mean a huge step backward for the quality of software written in .NET, but for LINQ this is great stuff.

WM.What about weapons of mass-construction?"What? Its an Apple MacBook Pro. They are sexy!" - Paul Watson

First of all, type inference shouln't be needed since .NET 2.0 introduced generics.
The idea of avoiding usage of system.object was a revolution, and using type parameters
is simple and clear. How does a "var" make the code easier to maintain than "MyClass"?
Why is it simpler to think every time you look at a method "which type did I assign to it first?"

Lambda expressions seem useful in some circumstances, but the syntax is a bit awkward.

It seems as that most of these "enhancements" are just "tools" to enable LINQ technology.
And then again, LINQ seems as a bad thing. As MS introduced it - it is a tool for
rapid app development, where developers need not to know TSQL or SQL administration.
How are those "rapidly developed" apps expected to scale? How are they maintained in production?
Optimized? DBAs are going to have hell of a time maintaining SQL servers that are accessed by LINQ.
Shouldn't there be a sync between developers and dbas while developing an app?

The .NET framework was supposed to be object oriented, and all that the version 3.5 is introducing
seems like going back to JavaScript. Maybe the point was that Silverlight programmers need not to know
much about oop, and still can develop in C# syntax. Silly. Btw, does that mean that Silverlight clients
can access a database using LINQ? I still havent studied Silverlight much.

Lambda has two purposes:
* a leaner syntax for anonymous delegates
* a way to specify data in code.

In practice, you probably won't have to worry about the difference since it will look and behave the same to you.
But the idea is that you can do:

from customer in db.Customers
where customer.IsValued==true
select customer;

And the where statement will actually get data that is can dissassemble and manipulate. This means that you can write code that is type checked and can be very easily be disassembled to get your meaning.
For instance, DLinq will take the data about customer.IsValued == true and turn it into an SQL fragement, etc.

In VB, "Dim a" is the same as "Dim a As Variant". That's dynamic typing (and VB is weakly-typed, too).

But type inference is different:
The type is still known at compile-time, you just don't have to write it.
Type inference is "implicit static typing".
It's much better than VB's implicit dynamic typing.

For example, the code:var a = 3;
a = "Text";
will cause an compiler error because a has the type int.

InOtherWordsVBIsLikeABadParentItCanReallyScrewUpYourChildhood a = new InOtherWordsVBIsLikeABadParentItCanReallyScrewUpYourChildhood();
- or -var a = new InOtherWordsVBIsLikeABadParentItCanReallyScrewUpYourChildhood();
- or -var a = InOtherWordsVBIsLikeABadParentItCanReallyScrewUpYourChildhood();

What you've posted there is totally different. You're telling the compiler to store a SoapHeader object as a System.Object. You lose strong typing and also induce boxing if the type is a value type (such as int, Point, double, etc).

C# 3's implementation does not lose strong typing; the compiler infers the type from the usage, meaning less typing for the developer at zero cost of performance.

Doing research before putting your fingers on the keyboard often makes you look smarter.

from VB 9.0:
In an implicitly typed local-variable declaration, the type of the local variable is inferred from the initializer expression on the right-hand side of a local declaration statement. For example, the compiler infers the types of all the following variable declarations:

I think Gary was referring to VB's loose/weak typing, so that's clearly VB 7/8. I know VB 9 is a great improvement, I think type inference and the other new features fit much better to VB than C#.
It's nice they still do breaking changes like this, C# designers do not even add new keywords to the language. (yield, partial etc. are not keywords).

Actually, if you take a look at things, they're simplifying the way things are done.

How many times have you had to re-create the way you search for objects in a list? How have you done that with a database? With XML? Answer: At least 3.

In how many different ways will you do it in C#3? Answer: one.

They're unifying APIs, and are taking extra time to do it right. Unfortunately, this means doing it only half-right the first time around (ADO.NET, for example).

Also, this is baked into the CLR, so any language can take advantage of it. I can see immediate application to Monad. In fact, much of Monad would be trivial within LINQ.

.NET 2.0 set up most of the machinery for doing LINQ -- LINQ is merely where it's been heading for the last few years. And after Orcas comes Hawai`i -- I'm hoping for distributed methods (a la MC#) in that one.

If we wanted to just limit new features to C#, we may as well not bother with this whole CLR thing. But that is not the .NET way of things -- if there's a powerful tool, go ahead and play with it in a language, and then figure out how the CLR could best bring that to everyone, regardless of language. That's what they did with C-omega. It's what they avoided when they decided not to go with ObjectSpaces.

And it seems to work for the better.

They did this with Generics, and behold! Generics are now available, yesterday, in C++, C#, VB, IronPython, and so forth.

Today, everyone can experiment with a powerful, strongly-typed, performant means of expressing queries, and we won't have to think about what the persistence mechanism is, if any. We won't have to worry about XML or SQL being made obsolete by the Next Big Thing. The query mechanism has been decoupled from the backing store, and that lends itself to better longevity.

I also expect we'll see stuff from Spec# pushed into the runtime in the 3.0 timeframe, as well as Polyphonic C#.

I also expect, after .NET has been around for another 5-10 years, that its successor will take a look at what we have, and remove the crufts left over from not-quite-perfect ideas, just as we did with C++, Java, MFC, Win32, and ADO, and just as they've done through the last couple years of working on Whidbey.

.NET isn't *about* any particular language (except, perhaps, IL). It's about the CLR, and making it as powerful and as friendly to language developers as possible. There are no performance or sanity gains in trying to work around a missing feature.

I am migrating to JAVA. I have fallen in love with C# for 3 years and now after my experiences with It in some big and average projects, I think It is a buzz oriented language. bye the .NET buzzwork! =)

Actually, if you look at it objectively, this isn't making C# more complex, but less so. We developers, on a daily basis, right code to iterate over data stores, filtering, sorting and transforming. Each and every data store has a different API. Many of those APIs require using complex syntax in the form of string parameters passed to functions that have to parse and interpret them at runtime. This is slower, less secure and provides no compile time verification. Further, all of these APIs require translations from one domain (the data store) to another (the CLR), and the translations are often not implicit but rather require explicit coding.

All of this means that even the simplest of examples using in memory objects represented in the native language still require more lines of code. The more complex the example, the more lines of code are different.

Example: We have an Employee object. From somewhere we've populated an array of these employee objects. So, we're going to deal with straight C# objects here. What's needed is to find all the employees who work for Manager X and sort the result by their salary. See how many lines of code this "trivial" task will take you in C# 2.0/1.1/1.0. In C# 3.0 it will require a single statement.

And the syntax is the same regardless of the data store used.

Not impressive enough? Imagine you have 3 data stores, one a DB, one a web service and a third an XML file. With LINQ you can create a complex join of all three data stores, sorting, filtering and transforming the results, again with a single statement. How complex would it be to do that in the "traditional" manner? Still think they are adding complexity? Well, either you'll have your mind changed over time or you'll be left in the dust by those that "get it", because this is truly what's needed for the future of all languages.

BTW, ECMA Script has a concept similar to this for XML data stores today in the form of a language extension called E4X. So others have already "gotten it".

kempf wrote:Example: We have an Employee object. From somewhere we've populated an array of these employee objects. So, we're going to deal with straight C# objects here. What's needed is to find all the employees who work for Manager X and sort the result by their salary. See how many lines of code this "trivial" task will take you in C# 2.0/1.1/1.0. In C# 3.0 it will require a single statement.

Just say this cannot be done unless it is built into a language, then you have a point.

I know about E4X, even though I have not used it before. For Javascript, it is nothing different, they are already doing similar thing with HTML, so why not with XML - that is all.