Re: I freaking HATE var!!

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<known type> as 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<Customer>
implementation (like an array) like this:

IEnumerable<PartialCustomer_Name_Age> query =
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]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx


.

Relevant Pages

  • Re: I freaking HATE var!!
    ... 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. ... 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. ... What I'm getting at is, if 'var' is the necessity of a new feature, my hatred of 'var' is greater than that feature. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: I freaking HATE var!!
    ... of other 3.0 features than what var uses, ... the syntax that translates queries from the C# 3.0 language and actually ... There are ALWAYS going to be new technologies that are coming out ... greater than that feature. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: best way to load arrays with large amounts of data?
    ... var a = new Array; ... Reading files or rather accessing resources is not a feature of the ... language, but a feature of an API that can be used by the language. ...
    (comp.lang.javascript)
  • Re: Yet Another Newbie Question
    ... client-side script support is not a viable option as that feature can ... Arrays in ECMAScript implementations are of dynamic length by nature. ... var e_cart_descr; ... Even if the declarations above were omitted, that does not make sense as ...
    (comp.lang.javascript)
  • Re: Javascript problems from a lightweight - xmlhttprequest and html fragments
    ... req = new XMLHttpRequest; ... var returnedText; ... but to do a feature test before you use the feature. ... iff you use them within the HTML `script' element. ...
    (comp.lang.javascript)
Loading