Nathan J Pledger

Program.X musings from the Isle of Man concerning ASP.NET, in particular accessibility, web standards and neat ideas.

C# 3.0 : Lax Programming

Reading www.thedailywtf.com today and I happened across this article about C# 3.0:

http://blogs.tedneward.com/2005/09/22/Language+Innovation+C+30+Explained.aspx

I've already mentioned I am unhappy with the LINQ implementation, in that it softens the difference between your tiers, but I accept it is a useful addition and am looking forward to using it myself - particularly for quick binding of controls.

This article really unnerves me though, it introduces some concepts which I feel would introduce lack coding practices. I was to believe C# would be type-strong, and that little more strict than C++.

Implicitly typed variables

Variables that imply their type on compilation, eg:

var i = 5;
var s = "This is an implicitly typed local variable";
var a = new int[] { 1, 2, 3 };

What happened to the type-strong C# I grew fond of? This is a reversion to the practices of a Variant, and the hassle that comes with it.

Object Initialisers

Instead of coding all those constructors, often repeating the same constructor logic, or at least calling the this constructor to make the code a little less repetitive. If you had a property PropertyA defined, then you could instantiate a new object by calling the ocnstructor, eg.:

MyObject o=new MyObject{PropertyA="Hello"};

But what if there was a reason why those properties were managed by the constructor?

I can see me having problems maintaining any sense of best practice in coding standards in ou team when this is implemented.

 

 

Posted: Jul 17 2006, 09:00 AM by Nathan Pledger | with 5 comment(s)

Comments

Ramon Smits said:

Implicit typed variables:
This is a c# feature that I am waiting for since I started programming! You really cannot compare it with variants because variants arent typed. Variants are just luxurious object references that still need interface casting to get the correct interface to work on.

var a = new int[] { 1, 2, 3 };

If you would debug this code then a will really be an integer array. Var is not really handy for standard types. It is very easy in scenarios where you have lots of data classes or situations where you don't have a stable data model yet.

Faulty variant handling can only be detected at runtime while the var keyword is replaced inline by the compiler with the return type of the expression being a method or statement. So you have compile-time checking of your code.

Object initializers:
I've always learned that constructors are there to initialize the invariants within your class. This reason will not change at all. This is just an aditional way of initializing object where normal invariants can always be initialized by the default constructor.
# July 17, 2006 1:47 AM

Jan Schreuder said:

Ramon, I have to agree with Nathan here. What's the point of having var. To me it sounds completely useless. Wow, the compiler replaces it with in integer array if you declare: var a = new int[] { 1, 2, 3 }; I can't think of any situation where you wouldn't just declare: int [] a = new int[] { 1, 2, 3 };
# July 17, 2006 3:02 AM

Erwyn van der Meer said:

I definitely see the power of C# 3.0 which means a lot less redundant typing. It also means C# can handle situations where you cannot sensibly specify the types you are using. For example when projecting out only a couple of fields using LINQ in a nested query.

C# 3.0 definitely stays on the strongly typed side of the language spectrum as Ramon explains. Don't let the vars fool you!

I have programmed a lot in JavaScript in the past (and in fact I am doing this for my current project) and I like the power of dynamically typed languages. VB 9.0 will have the best of both worlds ;) Only the syntax sucks ;(

# July 17, 2006 12:37 PM

Alex Thissen said:

My cents on this issue: var has nothing to do with dynamic typing, such as in JavaScript, Perl or Ruby. The compiler infers the actual type from the expression went it is initialized.
Also, I find that examples such as var foo = new int[] { 1, 2, 3 } could mislead the programmer into thinking it has no place in C#. var is not intended for these situations, because you know the exact type beforehand. Instead var is meant for situations where a new anonymous type is created, such as by projection from a linq expression.
var q = new { Name = "Alex", Age = 34 };
Now you do not know the name of the type, because it is not given a name by yourself, but by the compiler.
This is not lax programming, but programming with types beyond your initial data and object model.
# July 20, 2006 12:30 PM

Dennis van der Stelt said:

lol @ erwyn :)

Check out this explanation by Alex Thissen (my colleague :) about vars : http://www.alexthissen.nl/weblog/DetailsView.aspx?PostingID=593a19b3-fcfb-4c5d-9155-d96098f11064
# July 23, 2006 11:17 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)