I freaking HATE var!!

[Jon Davis]

Bill Wagner posted something here ..

http://msdn2.microsoft.com/en-us/vcsharp/default.aspx

"Local Type Inference, Anonymous Types, and var"
"Of all the features in C# 3.0, local type inference is generating the most
questions and misunderstandin g. You know, 'var'. The fact is local type
inference is not as scary as it seems. In fact, you're not losing strong
typing. It's a simple time saver that is actually necessary to support
anonymous types."

Great. I appreciate that it's "necessary" to support LINQ (and LINQ is the
only major reason why it's necessary to support anonymous types).

Well then I guess my issue is with anonymous types. But I dislike var. It is
stinky to my nostrils. Bill can argue till the cows come home that it's
still strongly typed and produces MSIL that is no different than C# 2.0
code. I don't care, it's not the MSIL that I have to stare at all day long.

It was only a couple years ago that I was running around singing the praises
of Microsoft and celebrating the wonderous, magical LINQ invention (back
then it was a Microsoft Research invention, C-Omega). Finally, SQL and C#
would be beautifully merged syntactically. So don't get me wrong, I
understand and appreciate LINQ's value.

But I also understand and appreciate the hell I went through, and why I am
so glad I went through it, to wean myself off of Visual Basic 6.0
(Variant-land) and javascript and vbscript, and into Java and C#. In gross
celebration of lessons learned, I hacked together a silly Variant object for
C#, just for fun.
http://www.planetsourcecode.com/vb/s...txtCodeId=2854

It didn't take long that I began really appreciating strongly typed
declarations. It had nothing to do with performance. It had little to do
with stability. It had mostly to do with the fact that as I'm scrolling up
and down in my code, or when I right-click a variable and choose "Go To
Definition", I immediately saw what the heck it was. Not what it was named.
Not what was assigned to it. But what it was.

So var produces strongly-typed MSIL. Great. But it's still anonymous.

Introducing var forces us to revert back to the old Hungarian notation style
naming conventions--that is, variables will have to have their types
inferred in the name. Yes, the type is strongly typed at compile-time. And
if Microsoft builds Visual Studio right, yes, IntelliSense tooltips will
reveal what type a variable is. But what if we don't want to hover over the
variable with the mouse? What if we're not using Visual Studio? When editing
code, if you have to do extra work of any sort to discover the type of a
variable, productivity is lost.

The biggest grief of var is that it's really only useful for LINQ+SQL, but
it will compel Variant-style VB coders and javascript script kiddies to
dilute the somewhat more disciplined structure of C# for no good reason.
Normal declarations that do not involve LINQ and could do just as well with
a standard type reference will use var instead....

var doc1 = myComplexObject .GetDoc();
// oh, by the way, GetDoc() returns a System.Xml.XmlD ocument

var doc2 = myOtherObject.G etDoc();
// oh, and um, GetDoc() returns a System.Windows. Forms.HtmlDocum ent

What's wrong with this picture? I'll tell you what's wrong: "var" sucks!!
There is nothing here that makes what doc1 and what doc2 are. The method
names of each object aren't necessarily wrong. But now they'd have to be
renamed to expose the type of data being returned. Where is the advantage?

Bill makes the lousy argument:
<quote>
string[] words = { "cherry", "apple", "blueberry" };

var sortedWords =
from w in words
orderby w
select w;

It's fairly obvious that sortedWords is some sequence of strings. (It's
actually a System.Query.Or deredSequence<s tring, string>). In my opinion,
OrderedSequence <string,stringd oesn't add any new information for me when I'm
trying to read this code. In fact, I think it's clearer with the var
keyword.
</quote>

No, Bill, when you hide the declaration of the "words" variable, it is not
obvious that sortedWords is some sequence of strings. What if a Words was an
array of a complex type called Word? And why are you limiting yourself to
words in these samples? How often do we have the luxury of working with
objects that are "obviously" composed of strings or arrays or collections
thereof?

Most often, types consist of all kinds of weird values. Even when pounding
against a SQL database table, a particular table could have an ID column
that could be an integer, it could be a string, it could be a GUID. Obvious?
No. Strongly typed? Sure, buried down the MSIL. But the only way we would be
able to find out what we're dealing with is if you actually dig into the
MSIL or open up the database designer or, more likely, SQL Server Management
Studio, and examine the design of the database table. Suddenly LINQ ain't so
time-saving.

What LINQ should have done is have strongly typed SQL statements rather than
infer the crap out of everything based on a remote database schema. Visual
Studio should have auto-generated some strongly-typed code based on a select
at design-time. You could have been just as lazy, but far more verbose.
Terseness getting severely overrated right now; I'm obviously speaking in
favor of verbosity.

Try "var" in another language. "Boo" for duck typing--I think Boo is a great
language. But don't corrupt C# with this insolent laziness.

"var" is an evil beast that will take an otherwise wonderful language and
make horrible programmers out of people. It will cause C# to be exactly what
VB.NET already is -- a strongly-typed language that is very powerful but
that is used by undisciplined people who are too lazy and undisciplined, or
most often just plain too ignorant, to know how to write well-defined,
clearly readable, well-designed, easily maintainable code.

If only it wasn't too late. The tsunami is coming. But our engineering team
will NOT take the plunge into C# 3.0.

Jon

[Nicholas Paldino [.NET/C# MVP]]

Not to marginalize your post, but your last statement pretty much axes
all the effort you put into it:

If only it wasn't too late. The tsunami is coming. But our engineering team
will NOT take the plunge into C# 3.0.

If you don't like it, don't use it, end of story. Outside of how you
use it, and the engineering team that you work with uses it, what do you
care if someone else uses it? It's not going to break any of the code you
have now, so that's a non-issue. Your coding standards are going to dictate
what you can use and how you name your variables, and your ecosystem will be
preserved.

The only thing I think that Bill is wrong on is that in the example that
selects strings from an array of strings, it should be assigned to
IEnumerable<str ing>. I agree, var shouldn't be used in cases where you know
the type, and in this case, you do know the type that is being returned.
However, in order to get projections to work, there is no way around var.

Granted, having VS.NET wire up the code for you in known types will be
nice (and it should do something like this, converting projections/anonymous
types to known-types), but the amount of code you would have to write by
hand if you didn't have VS is enormous, and they can't depend on the IDE to
pick up where language features fail.

I agree that those that use var when they know the type of what is being
used (and yes, even in the case of those long generic types, use the using
directive to alias it instead) should be skewered, but really, it's not that
bad.

It's also Friday, I'd save this kind of rhetoric-filled post for Monday.
That's what Monday's are for.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Jon Davis" <jo*@REMOVE.ME. PLEASE.jondavis .netwrote in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..

Bill Wagner posted something here ..

http://msdn2.microsoft.com/en-us/vcsharp/default.aspx

"Local Type Inference, Anonymous Types, and var"
"Of all the features in C# 3.0, local type inference is generating the
most questions and misunderstandin g. You know, 'var'. The fact is local
type inference is not as scary as it seems. In fact, you're not losing
strong typing. It's a simple time saver that is actually necessary to
support anonymous types."

Great. I appreciate that it's "necessary" to support LINQ (and LINQ is the
only major reason why it's necessary to support anonymous types).

Well then I guess my issue is with anonymous types. But I dislike var. It
is stinky to my nostrils. Bill can argue till the cows come home that it's
still strongly typed and produces MSIL that is no different than C# 2.0
code. I don't care, it's not the MSIL that I have to stare at all day
long.

It was only a couple years ago that I was running around singing the
praises of Microsoft and celebrating the wonderous, magical LINQ invention
(back then it was a Microsoft Research invention, C-Omega). Finally, SQL
and C# would be beautifully merged syntactically. So don't get me wrong, I
understand and appreciate LINQ's value.

But I also understand and appreciate the hell I went through, and why I am
so glad I went through it, to wean myself off of Visual Basic 6.0
(Variant-land) and javascript and vbscript, and into Java and C#. In gross
celebration of lessons learned, I hacked together a silly Variant object
for C#, just for fun.
http://www.planetsourcecode.com/vb/s...txtCodeId=2854

It didn't take long that I began really appreciating strongly typed
declarations. It had nothing to do with performance. It had little to do
with stability. It had mostly to do with the fact that as I'm scrolling up
and down in my code, or when I right-click a variable and choose "Go To
Definition", I immediately saw what the heck it was. Not what it was
named. Not what was assigned to it. But what it was.

So var produces strongly-typed MSIL. Great. But it's still anonymous.

Introducing var forces us to revert back to the old Hungarian notation
style naming conventions--that is, variables will have to have their types
inferred in the name. Yes, the type is strongly typed at compile-time. And
if Microsoft builds Visual Studio right, yes, IntelliSense tooltips will
reveal what type a variable is. But what if we don't want to hover over
the variable with the mouse? What if we're not using Visual Studio? When
editing code, if you have to do extra work of any sort to discover the
type of a variable, productivity is lost.

The biggest grief of var is that it's really only useful for LINQ+SQL, but
it will compel Variant-style VB coders and javascript script kiddies to
dilute the somewhat more disciplined structure of C# for no good reason.
Normal declarations that do not involve LINQ and could do just as well
with a standard type reference will use var instead....

var doc1 = myComplexObject .GetDoc();
// oh, by the way, GetDoc() returns a System.Xml.XmlD ocument

var doc2 = myOtherObject.G etDoc();
// oh, and um, GetDoc() returns a System.Windows. Forms.HtmlDocum ent

What's wrong with this picture? I'll tell you what's wrong: "var" sucks!!
There is nothing here that makes what doc1 and what doc2 are. The method
names of each object aren't necessarily wrong. But now they'd have to be
renamed to expose the type of data being returned. Where is the advantage?

Bill makes the lousy argument:
<quote>
string[] words = { "cherry", "apple", "blueberry" };

var sortedWords =
from w in words
orderby w
select w;

It's fairly obvious that sortedWords is some sequence of strings. (It's
actually a System.Query.Or deredSequence<s tring, string>). In my opinion,
OrderedSequence <string,stringd oesn't add any new information for me when
I'm trying to read this code. In fact, I think it's clearer with the var
keyword.
</quote>

No, Bill, when you hide the declaration of the "words" variable, it is not
obvious that sortedWords is some sequence of strings. What if a Words was
an array of a complex type called Word? And why are you limiting yourself
to words in these samples? How often do we have the luxury of working with
objects that are "obviously" composed of strings or arrays or collections
thereof?

Most often, types consist of all kinds of weird values. Even when pounding
against a SQL database table, a particular table could have an ID column
that could be an integer, it could be a string, it could be a GUID.
Obvious? No. Strongly typed? Sure, buried down the MSIL. But the only way
we would be able to find out what we're dealing with is if you actually
dig into the MSIL or open up the database designer or, more likely, SQL
Server Management Studio, and examine the design of the database table.
Suddenly LINQ ain't so time-saving.

What LINQ should have done is have strongly typed SQL statements rather
than infer the crap out of everything based on a remote database schema.
Visual Studio should have auto-generated some strongly-typed code based on
a select at design-time. You could have been just as lazy, but far more
verbose. Terseness getting severely overrated right now; I'm obviously
speaking in favor of verbosity.

Try "var" in another language. "Boo" for duck typing--I think Boo is a
great language. But don't corrupt C# with this insolent laziness.

"var" is an evil beast that will take an otherwise wonderful language and
make horrible programmers out of people. It will cause C# to be exactly
what VB.NET already is -- a strongly-typed language that is very powerful
but that is used by undisciplined people who are too lazy and
undisciplined, or most often just plain too ignorant, to know how to write
well-defined, clearly readable, well-designed, easily maintainable code.

If only it wasn't too late. The tsunami is coming. But our engineering
team will NOT take the plunge into C# 3.0.

Jon

[Jon Davis]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c omwrote in
message news:%2******** **********@TK2M SFTNGP06.phx.gb l...

Not to marginalize your post, but your last statement pretty much axes
all the effort you put into it:

If only it wasn't too late. The tsunami is coming. But our engineering
team will NOT take the plunge into C# 3.0.

If you don't like it, don't use it, end of story.

While I won't, the basis of my frustration was the other coders--not myself.
I know how to write good code. It's having to support the output of coders
who code as if they just learned VBScript that is bothering me.

Outside of how you use it, and the engineering team that you work with
uses it, what do you care if someone else uses it?

Because "it" very quickly dwindles into a proprietary standard.

It's not going to break any of the code you have now, so that's a
non-issue.

Thank God. But I still hate var.

Your coding standards are going to dictate what you can use and how you
name your variables, and your ecosystem will be preserved.

Yes, *my* coding standards. *Our* coding standards. But by our being forced
to stick with v2.0 in order to avoid var,

a) our team would be forced to withhold ourselves from taking advantage of
other 3.0 features than what var uses,

b) I personally, and the other engineers on our team, would be presented
with an unpredicted and undesirable dillemma of whether to offer engineering
services, whether to the public or to an employer, as a C# 2.0 purist or as
a C# 3.0 cutting edge Microsoftie who drinks all the kool aid that gushes
out of the fountains of Redmond and participates in the very bandwagon that
will ultimately make a mess of the output of C# coders everywhere, and

c) put in context, the point was, add us to the list of people who don't
subscribe to the appreciation of 'var'. "Don't like it, don't use it,"
phooey, what are you doing here? I'm here to discuss this sort of
stuff--even if in a monologuish soapbox stance. :p

However, in order to get projections to work, there is no way around var.

Yes. There is. Auto-generate the inferred type information directly in the
code rather than at compile time. Actually, you and others talk as if
projections were a necessity in themselves. What I'm getting at is, if 'var'
is the necessity of a new feature, my hatred of 'var' is greater than that
feature. I loved the LINQ idea, but that was when I heard about C-Omega as
C#-based language, not as C# v3, supposed successor to the language I work
with everyday.

Granted, having VS.NET wire up the code for you in known types will be
nice (and it should do something like this, converting
projections/anonymous types to known-types), but the amount of code you
would have to write by hand if you didn't have VS is enormous, and they
can't depend on the IDE to pick up where language features fail.

That doesn't make sense to me. I see var as the failure. But at least we
agree that VS should try to auto-populate "var" with known types.

I agree that those that use var when they know the type of what is
being used (and yes, even in the case of those long generic types, use the
using directive to alias it instead) should be skewered, but really, it's
not that bad.

Not that bad? I spend half my coding time already pulling my hair out
looking at other people's lazily written or generated code--XML node or
Control lookups that should have been referenced by name or ID are instead
referenced by index, referenced ASP.NET control names plopped in with
namespace of "uc1" rather than origin, variable names as numbered type names
rather than purpose, little "thorn in the side" things that make my job one
minor bit less enjoyable. And now 'var'? Ugh.

It's also Friday, I'd save this kind of rhetoric-filled post for
Monday. That's what Monday's are for.

LOL .. well we differ here :) I use the weekends to zoom out and ask myself
questions like what the heck am I doing it all for.

....

[Chris Nahr]

I'm pretty sure I've never seen a more hilarious overreaction to a
tiny new feature, and I've been reading programming newsgroups for a
long time...
--
http://www.kynosarges.de

[Jon Davis]

"Chris Nahr" <di******@kynos arges.dewrote in message
news:f8******** *************** *********@4ax.c om...

I'm pretty sure I've never seen a more hilarious overreaction to a
tiny new feature, and I've been reading programming newsgroups for a
long time...
--
http://www.kynosarges.de

The sky is falling!!

Jon

[OD]

What you're saying about 'var' is not false, there is a risk to see C#
code becoming like interpreted msbasic of the 70's ..
But LINQ is a so big progress, really fantastic, that perhaps, the wise
developer will only use 'var' in this context.
Bill will not come in your back when you're coding to force you using
'var', do as you feel :-)

--
OD___
www.e-naxos.com

[Alun Harford]

Jon Davis wrote:

>
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c omwrote
in message news:%2******** **********@TK2M SFTNGP06.phx.gb l...

> Not to marginalize your post, but your last statement pretty much
axes all the effort you put into it:

If only it wasn't too late. The tsunami is coming. But our engineering
team will NOT take the plunge into C# 3.0.

If you don't like it, don't use it, end of story.

While I won't, the basis of my frustration was the other coders--not
myself. I know how to write good code. It's having to support the output
of coders who code as if they just learned VBScript that is bothering me.

People who can't write decent code for toffee will write bad code with
or without var. Just remember two rules:
1) If you have such programmers on your team, they need 'moving into a
different role' (ie. moving far away from you).
2) Don't buy code written by idiots.

If, for some reason, you break one of those two rules, I'm sure the fact
that they used var all over the place will be the least of your
worries... (particularly since it'll be easy to make, or download, a
tool to parse the C# and convert all those vars into 'properly' typed
variables)

Alun Harford

[Nicholas Paldino [.NET/C# MVP]]

Jon,

See inline:

a) our team would be forced to withhold ourselves from taking advantage of
other 3.0 features than what var uses,

No, you won't. You can eschew var, as well as extension methods, and
the syntax that translates queries from the C# 3.0 language and actually
chain the static method calls yourself, passing anonymous delegates and
known types as the return. Granted, it is going to be a ROYAL PITA but it
^IS^ possible.

b) I personally, and the other engineers on our team, would be presented
with an unpredicted and undesirable dillemma of whether to offer
engineering services, whether to the public or to an employer, as a C# 2.0
purist or as a C# 3.0 cutting edge Microsoftie who drinks all the kool aid
that gushes out of the fountains of Redmond and participates in the very
bandwagon that will ultimately make a mess of the output of C# coders
everywhere, and

Well, welcome to the wonderful world of software engineering. "It ain't
just static" should be the motto. That's just the nature of the beast.
There are ALWAYS going to be new technologies that are coming out and you,
being a professional in the field, will have to decide on how you want to
leverage those technologies in what you do to provide for how you make a
living. You aren't the first person to have to face this, and you won't be
the last.

c) put in context, the point was, add us to the list of people who don't
subscribe to the appreciation of 'var'. "Don't like it, don't use it,"
phooey, what are you doing here? I'm here to discuss this sort of
stuff--even if in a monologuish soapbox stance. :p

I was trying to respond to what was a predominantly rhetoric-filled
post. Granted, you have some very valid, and very good points, some of
which I agree with (VS being able to generate known types) and some which I
don't agree with (var is evil). However, the rhetoric gets in the way

>However, in order to get projections to work, there is no way around var.

Yes. There is. Auto-generate the inferred type information directly in the
code rather than at compile time. Actually, you and others talk as if
projections were a necessity in themselves. What I'm getting at is, if
'var' is the necessity of a new feature, my hatred of 'var' is greater
than that feature. I loved the LINQ idea, but that was when I heard about
C-Omega as C#-based language, not as C# v3, supposed successor to the
language I work with everyday.

Doing work with SQL, you realize that projections become necessary VERY
quickly. Ok, I don't want to be absolute. COULD you get away without
having them, yes, absolutely, but again, ROYAL PITA. I'm not against doing
something that takes a lot of work because it is the right thing to do, but
LINQ here is trying to bridge that gap between the relational and procedural
models. The relational model (as represented by the implementation of the
SQL standard across many database products) depends heavily on projections.
It's something that they probably feel they couldn't leave out.

Now, I agree, I do hope, and expect, quite frankly, that VS.NET will be
able to take your anonymous types and make known types. If it has that
facility, then you can still code in your 2.0 style, and pass back
IEnumerable<kno wn typeas the return values of the calls to the LINQ
library functions (you might have to cave and use the assignment feature in
C# 3.0 though).

However, this is what I meant by you shouldn't depend on tools to fill
in the gap where the language fails. You can't expect that everyone will
have VS.NET installed. Hell, I've written code in notepad before, others
write code in Eclipse, someone is writing C# code in Emacs as well. Those
tools can not be depended on to support the feature.

Not that bad? I spend half my coding time already pulling my hair out
looking at other people's lazily written or generated code--XML node or
Control lookups that should have been referenced by name or ID are instead
referenced by index, referenced ASP.NET control names plopped in with
namespace of "uc1" rather than origin, variable names as numbered type
names rather than purpose, little "thorn in the side" things that make my
job one minor bit less enjoyable. And now 'var'? Ugh.

You see the potential for abuse here because of the ways that other
technologies have been abused in the past by people that don't have an
understanding of those technologies.

I get that, completely. I respect it tremendously.

There are always going to be people who don't know what the best way to
do things are. The ones that do it out of ignorance which they choose to
perpetuate are never going to advance in this field, while the ones that are
not ignorant are going to learn and perpetuate (hopefully) best practices.

If the case where that as a society we restricted all growth and
innovation because of the potential for abuse of those innovations, then we
would still be living in caves without fire.

So this leads to what I think you and your team should do in respects to
C# 3.0. Don't give up on it, and certainly don't throw it away. You are
throwing away a HUGE amount of benefit for one simple language feature which
you don't like, don't have to use, and can get around and still gain the
benefits of.

For example, say you had your class:

public class Customer
{
public string Name;
public int Age;
public string Address;
}

And you wanted a query that returns just the name and age. Well,
hopefully the tooling will support it (from anonymous types), and if it
doesn't, you can always code by hand, the following:

// Ok, the naming here is abhorrent, but that's not the point.
public class PartialCustomer _Name_Age
{
public string Name;
public int Age
}

And then you can perform your query on an IEnumerable<Cus tomer>
implementation (like an array) like this:

IEnumerable<Par tialCustomer_Na me_Agequery =
from c in customers
select new PartialCustomer _Name_Age(){ Name = c.Name, Age = c.Age };

No var at all!

LOL .. well we differ here :) I use the weekends to zoom out and ask
myself questions like what the heck am I doing it all for.

Money? You like it? The women?

While I am making light of it, I do hate the idea of seeing someone in
this profession asking these questions because of something they don't like,
when there is so much more about this field which can be enjoyed.

Kind of like anything else. =) Enjoy the weekend.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I agree that there is a possibility to misuse the var keyword, and I
have no doubt that some people will, but I don't think that there is any
reason to fear that we will move into the medeval times of programming
that you describe.

As comparison, you can look at the VB.NET language. There you don't even
have to declare the variables if you don't want to, and you can mix data
types back and forth to produce monstrosities like:

a = "35"
a = a + 7

(What is the result? 42, "42", 357 or "357"? That's not exactly obvious.)

Still, there is very little VB.NET code that actually look like this,
simply beacuse almost everyone knows that you can't write good code this
way.

Similarly, it should not be a big problem to educate people of the
proper use of the var keyword.

--
Göran Andersson
_____
http://www.guffa.com

[Jon Davis]

Nicholas,

Bravo. Yours is the kind of response I highly admire and respect. You don't
patronize nor insult me. You examine what I have to say, not who I am or how
well I'm doing (although the "welcome to the world of software development"
comment was a little presumptuous of a lack of experience with the industry,
but I'll take it tongue-in-cheek). And your response went well beyond the
level of appreciable merit than my light-hearted melodrama (which was
sincere nonetheless).

I'll take your thoughts to heart.

Thanks,
Jon

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c omwrote in
message news:OA******** ******@TK2MSFTN GP03.phx.gbl...

Jon,

See inline:

>a) our team would be forced to withhold ourselves from taking advantage
of other 3.0 features than what var uses,

No, you won't. You can eschew var, as well as extension methods, and
the syntax that translates queries from the C# 3.0 language and actually
chain the static method calls yourself, passing anonymous delegates and
known types as the return. Granted, it is going to be a ROYAL PITA but it
^IS^ possible.

>b) I personally, and the other engineers on our team, would be presented
with an unpredicted and undesirable dillemma of whether to offer
engineering services, whether to the public or to an employer, as a C#
2.0 purist or as a C# 3.0 cutting edge Microsoftie who drinks all the
kool aid that gushes out of the fountains of Redmond and participates in
the very bandwagon that will ultimately make a mess of the output of C#
coders everywhere, and

Well, welcome to the wonderful world of software engineering. "It
ain't just static" should be the motto. That's just the nature of the
beast. There are ALWAYS going to be new technologies that are coming out
and you, being a professional in the field, will have to decide on how you
want to leverage those technologies in what you do to provide for how you
make a living. You aren't the first person to have to face this, and you
won't be the last.

>c) put in context, the point was, add us to the list of people who don't
subscribe to the appreciation of 'var'. "Don't like it, don't use it,"
phooey, what are you doing here? I'm here to discuss this sort of
stuff--even if in a monologuish soapbox stance. :p

I was trying to respond to what was a predominantly rhetoric-filled
post. Granted, you have some very valid, and very good points, some of
which I agree with (VS being able to generate known types) and some which
I don't agree with (var is evil). However, the rhetoric gets in the way

>>However, in order to get projections to work, there is no way around
var.

Yes. There is. Auto-generate the inferred type information directly in
the code rather than at compile time. Actually, you and others talk as if
projections were a necessity in themselves. What I'm getting at is, if
'var' is the necessity of a new feature, my hatred of 'var' is greater
than that feature. I loved the LINQ idea, but that was when I heard about
C-Omega as C#-based language, not as C# v3, supposed successor to the
language I work with everyday.

Doing work with SQL, you realize that projections become necessary VERY
quickly. Ok, I don't want to be absolute. COULD you get away without
having them, yes, absolutely, but again, ROYAL PITA. I'm not against
doing something that takes a lot of work because it is the right thing to
do, but LINQ here is trying to bridge that gap between the relational and
procedural models. The relational model (as represented by the
implementation of the SQL standard across many database products) depends
heavily on projections. It's something that they probably feel they
couldn't leave out.

Now, I agree, I do hope, and expect, quite frankly, that VS.NET will be
able to take your anonymous types and make known types. If it has that
facility, then you can still code in your 2.0 style, and pass back
IEnumerable<kno wn typeas the return values of the calls to the LINQ
library functions (you might have to cave and use the assignment feature
in C# 3.0 though).

However, this is what I meant by you shouldn't depend on tools to fill
in the gap where the language fails. You can't expect that everyone will
have VS.NET installed. Hell, I've written code in notepad before, others
write code in Eclipse, someone is writing C# code in Emacs as well. Those
tools can not be depended on to support the feature.

>Not that bad? I spend half my coding time already pulling my hair out
looking at other people's lazily written or generated code--XML node or
Control lookups that should have been referenced by name or ID are
instead referenced by index, referenced ASP.NET control names plopped in
with namespace of "uc1" rather than origin, variable names as numbered
type names rather than purpose, little "thorn in the side" things that
make my job one minor bit less enjoyable. And now 'var'? Ugh.

You see the potential for abuse here because of the ways that other
technologies have been abused in the past by people that don't have an
understanding of those technologies.

I get that, completely. I respect it tremendously.

There are always going to be people who don't know what the best way to
do things are. The ones that do it out of ignorance which they choose to
perpetuate are never going to advance in this field, while the ones that
are not ignorant are going to learn and perpetuate (hopefully) best
practices.

If the case where that as a society we restricted all growth and
innovation because of the potential for abuse of those innovations, then
we would still be living in caves without fire.

So this leads to what I think you and your team should do in respects
to C# 3.0. Don't give up on it, and certainly don't throw it away. You
are throwing away a HUGE amount of benefit for one simple language feature
which you don't like, don't have to use, and can get around and still gain
the benefits of.

For example, say you had your class:

public class Customer
{
public string Name;
public int Age;
public string Address;
}

And you wanted a query that returns just the name and age. Well,
hopefully the tooling will support it (from anonymous types), and if it
doesn't, you can always code by hand, the following:

// Ok, the naming here is abhorrent, but that's not the point.
public class PartialCustomer _Name_Age
{
public string Name;
public int Age
}

And then you can perform your query on an IEnumerable<Cus tomer>
implementation (like an array) like this:

IEnumerable<Par tialCustomer_Na me_Agequery =
from c in customers
select new PartialCustomer _Name_Age(){ Name = c.Name, Age = c.Age };

No var at all!

>LOL .. well we differ here :) I use the weekends to zoom out and ask
myself questions like what the heck am I doing it all for.

Money? You like it? The women?

While I am making light of it, I do hate the idea of seeing someone in
this profession asking these questions because of something they don't
like, when there is so much more about this field which can be enjoyed.

Kind of like anything else. =) Enjoy the weekend.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m