As part of looking at the C# 4.0 CTP, I thought I’d best get up to speed with the previous “improvements” provided to C# in the guise of C# 3.0. These are:
- Auto-Implemented Properties. You no longer have to write the standard plumbing code (get{return _x;} or set {_x = value;}). Declare the property as you would in an interface and C# 3.0 will do the rest.
- Implicitly Typed Local Variables. Strongly-typed variables who’s types are inferred at compile time by looking at the value you assign.
- Implicitly Typed Arrays. Same as above only for arrays.
- Object and Collection Initialisers. A short-hand to creating and initialising types in one step.
- Anonymous Types. Define and initialise a new type of object on the fly at run-time.
- Extension Methods. You can add your own methods to other people’s classes without recompiling their code.
- Lambda Expressions. The next step in anonymous method evolution.
- Query Expressions. LINQ. Allows the developer to query constructs from within their code in a similar manner that a DB developer would query a database using SQL.
- Expression Trees. A “tree” of elements that represent an expression that can be compiled and executes at run-time.
These enhancements are of varying use and scariness and are worthy of investigation. Expression trees have the power to transform the world whereas implicitly typed variables have the power to make lazy developers even more lazy and poor code even worse.
Already I find myself telling off developers who have completely removed any standard variable definition in favour of needlessly using implicitly typed variables and it is driving me mad. Too many times developers see a new feature as the only feature and use it to death, to the detriment of maintainability and common sense. Anyway, that is for another time.
In C# 3.0 Enhancements (part 1) I’ll start to go through these new features and then jump into C# 4.0.
Tags: C#
I agree with you about implicit typing. I haven’t seen much take-up of this, luckily. Good for quick prototyping - very bad for production quality.
Extension methods can be very useful - I could add some convenience methods to the interface where they logically belonged without changing the interface itself. Also means that none of the classes that implemented the interface required any modification. Big win.
LINQ against SQL Server seems to run into limitations very quickly or maybe I did not persevere for long enough. Maybe a little like C++ templates, really simple to use but as soon as you run into a problem, the effort of trying to fix it becomes huge.
The LINQ extensions to IEnumerable are very useful - especially Count() - but I am a big fan of IEnumerable because of its immutability.
Lamda expressions and Expression trees are world changing like you say but I suspect that they will never really be understandable for all us mere mortals. At least LINQ makes them simpler.
I agree with everything that you said (I’ve just not posted that far into the enhancements yet) although LINQ to SQL is being discouraged I believe due to the inevitable architectural silliness that it encourages.
I’ll get through C# 3.0 just in time for C# 4.0 hopefully.