C# 3.0 with steps backwards?
Posted on March 8, 2006
Filed Under /dev/code/ | 598 views |
I’m a big fan of C# as a language, I think Microsoft’s done a hell of a job with and it’s far easier to use than Obj-C or Java (quite probably because of the IDE, which is unparalleled - how’s that for some flame-bait?) so I’m a bit surprised, if the post contains actual factual data, that Microsoft seems to be moving the language backwards a bit.
In New language features in C# 3.0 on CodePost they mention the addition of a var keyword which leaves it to the compiler to figure out the correct datatype by inferring it from the value on the right-hand side of the equation.
The fundamental question here is: is C# strongly-typed or loosely-typed? One way or the other is good, but both is bad. Both starts to slide C# towards VB.Net and no one should have to suffer another one of those. In my opinion, and I have many, if the developer has to worry about the type of the variable anywhere in the language, then they should have to worry about it everywhere. It seems to me that all var does is muddy the waters, make comprehension more difficult since now the developer needs to the do the same thing the compiler does: look at the right to figure out what they’re dealing with. I can’t see using this at all, it strikes me as a concession to VB developers wanting to step it up to C#.
Object initializers also don’t impress me much. In my day (last month or so) we just over-loaded the constructor. Again this feels like a PHP-like move towards loosening up the language but in an inherently strongly-typed language this fluidity may just cause code confusion. Again, feels like a concession.
Anonymous types - that’s pretty cool conceptually though I’m having a hard time thinking of a good practical use for them. If you have one, share.
I’m looking forward to more details on the language as 3.0 continues to evolve. Hopefully they won’t continue the move towards a more PHP-like or VB-like direction (and no, I’m not comparing PHP to VB, they’re worlds apart in quality so settle down y’all).
Comments
7 Responses to “C# 3.0 with steps backwards?”
Leave a Reply
Did you read the comments? var is strongly typed. It’s inferred by the _compiler_, not by the runtime (well, yes, by the runtime as well, but at that point it’s already been declared strongly). The example (which is totally not what this is meant for, really, but will do for illustrative purposes):
// old
string s = “The quick brown fox…”;
int i = 10;
// new
var s = “The quick brown fox…”;
var i = 10;
Both _compile_ to the same thing. The fact is in this instance it’s pretty useless - using var gets you nothing.
To me, the confusion lies with the keyword they chose - ‘var’. There are too many associations (again - read the comments…Flash people saying C# is using var to try and ‘get’ them…man…) with other language, be it Actionscript , VB (ugh), or Javascript. The C++ implementation of essentially the same idea uses the ‘auto’ keyword. Quite frankly, I’d think the keyword could be ‘infer’, as that makes a whole lot of sense.
Two place where I see var coming in handy:
Dictionary> myDictionary = new Dictionary>();
vs:
var myDictionary = new Dictionary>();
And, probably more importantly, all the new shtuff with LINQ, which, from the little I’ve read about it, seems very cool.
Bottom line: don’t look at these features as ‘loosening up’ the language…think of it more as adding more functional language features (a la OCaml or F#), for doing some really cool stuff that I don’t have the head to get into.
I’m acutely aware they’re determined at compile-time and not runtime, a factor that prompted my comment that it is a concession as opposed to an actual shift in direction. That doesn’t change the fact that it now muddies the code and removes clarity.
Regarding your dictionary example, I don’t see anything in there that makes a case for it, except for having to type less characters at the beginning. Am I missing something?
Ick. Your comments killed my generics. In that case the var is actually slightly more readable.
Again, the real power of the keyword is when it comes to LINQ and anonymous types. Arguably, both C# and Java have always had var functionality built in - just type everything as ‘object’. Of course, that’s a bad idea, and is actually worse than using var. But again, it’s not the intended usage scenario.
On of the comments on the link pointed out that it would make sense if var was only allowed when using an anonymous type. Which actually makes sense to me - the keyword is limited to being used in the scenario for which it was created. With that in mind, I don’t see this as a ‘concession’ - it’s a feature implemented for a specific purpose.
Also, object initializers and constructor overloading solve two different issues. This is definitely a readability thing, as with overloaded constructors, the intent of a string literal or boolean or number (or whatever) is not immediately understood (as one commenter made the point).
Person me = new Person( “Jason”, “Nussbaum”, true );
doesn’t stop me from mixing up the first and last names. Not to mention wtf is true? (Granted, intellisense cleans this up). But it’s an issue that an overload can’t solve - you can’t re-order two string arguments.
Person me = new Person { FirstName = “Jason”, etc };
makes the intent more readable. And can also be used where there are properties to be set that aren’t included in the constructor…
Also note that the Dictionary line should have read:
Dictionary<string, <s;List<string>>> myDictionary = new Dictionary<string, <s;List<string>>>();
assuming your comments script doesn’t kill my entities.
Or I don’t mess them up.
Dictionary<string, <List<string>>> myDictionary = new Dictionary<string, <List<string>>>();
Dictionary<string, <List<string>>> myDictionary = new Dictionary<string, <List<string>>>();
I give up.
Ok, your dictionary example makes much more sense now with the actual content in it, thanks a lot comment filter. I’m still not sold on var yet, but as I wish I’d noted in the original post I’m waiting for the definitive ‘Microsoft’-suggested way before passing final judgement.
As for object initializers its true that a constructore does allow you to mix up data of like types and that when reading the constructor you don’t have any idea of what the properties being passed in are (see Objective-C for a very nice implementation of this in which you do, easily the most readable constructor syntax I’ve seen… except for the wonky bits afterwards).
However the use of constructors ensures that while you may mix up all three properties, you need to have three properties in order to instantiate the object. Using initializers that seems to go out the window. I remain unconvinced on these.
I checked out LINQ this morning at about 3am but it was more than my brain could handle at that time. Maybe later today….