implicit types in C# 3.0, what is the usefulness of them?

[Guest]

It helps the VB.NET programmer make the transition.

The use is not evident in something as simple as:

var i = 1;
var s = "string";

It becomes more useful when dealing with array types, esp. if you are lazy.


var i = { 1, 2, 3, 4 };
var s = { "1", "2", "3", "4" };

I am not fond of implicit code, so I will have to see a good treatise before
jumping on this bandwagon.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Daniel O'Connell [C# MVP]]

It helps the VB.NET programmer make the transition.

The use is not evident in something as simple as:

var i = 1;
var s = "string";

It becomes more useful when dealing with array types, esp. if you are
lazy.

I prefer it for generics:

Dictionary<int, Dictionary<int, Dictionary<string,int>>> dictionary = new
Dictionary<int, Dictionary<int, Dictionary<string,int>>>()

vs.

var dictionary = new Dictionary<int, Dictionary<int,
Dictionary<string,int>>>();

Now, if var was the way to go, I don't know. It could have some issues with
ref and out parameters, but it does solve those problems and the anonymous
type problem.

 

[Jon Skeet [C# MVP]]

I prefer it for generics:

Dictionary<int, Dictionary<int, Dictionary<string,int>>> dictionary = new
Dictionary<int, Dictionary<int, Dictionary<string,int>>>()

vs.

var dictionary = new Dictionary<int, Dictionary<int,
Dictionary<string,int>>>();

How about using a "using" directive to give it a more meaningful name
though? That would make the code more readable for both the declaration
and the initialisation.

Now, if var was the way to go, I don't know. It could have some issues with
ref and out parameters, but it does solve those problems and the anonymous
type problem.

It certainly solves the anonymous types problem

 

[Daniel O'Connell [C# MVP]]

How about using a "using" directive to give it a more meaningful name
though? That would make the code more readable for both the declaration
and the initialisation.

Because then determining the actual type requires reading the using
statement, and I don't consider pretending that you have a third type more
readable, to be honest. var atleast tells me explicitly that the type is not
determined here, a using alias doesn't.


using DictionaryOfDictionaryOfDictionary=new Dictionary<int, Dictionary<int,
Dictionary<string,int>>>;

//100 lines

DictionaryOfDictionaryOfDictionary x;

//can you really tell me that makes things better than

var x = new Dictionary<int, Dictionary<int, Dictionary<string,int>>>();

//which has the literal type right there, not 100 lines above the use of the
alias type?

 

[Jon Skeet [C# MVP]]

Because then determining the actual type requires reading the using
statement, and I don't consider pretending that you have a third type more
readable, to be honest. var atleast tells me explicitly that the type is not
determined here, a using alias doesn't.

What do you mean by "not determined here"? As I understand it, the type
absolutely *is* known at that type.

using DictionaryOfDictionaryOfDictionary=new Dictionary<int, Dictionary<int,
Dictionary<string,int>>>;

//100 lines

DictionaryOfDictionaryOfDictionary x;

//can you really tell me that makes things better than

var x = new Dictionary<int, Dictionary<int, Dictionary<string,int>>>();

//which has the literal type right there, not 100 lines above the use of the
alias type?

No - but then I wouldn't use it in that way. I'd try to give it a
*semantically meaningful* name which makes the precise type either
obvious or irrelevant. For instance, AgeToNameMap is likely to be int
to string, and far more useful than Dictionary<int,string>.

Of course, one difficulty is that I prefer to use the *interface* type
rather than the concrete type wherever possible - and neither solution
solves that problem...

 

[Jon Skeet [C# MVP]]

What do you mean by "not determined here"? As I understand it, the type
absolutely *is* known at that type.

Whoops - I mean it's known at that *time*.

No - but then I wouldn't use it in that way. I'd try to give it a
*semantically meaningful* name which makes the precise type either
obvious or irrelevant. For instance, AgeToNameMap is likely to be int
to string, and far more useful than Dictionary<int,string>.

Of course, one difficulty is that I prefer to use the *interface* type
rather than the concrete type wherever possible - and neither solution
solves that problem...

I meant to go into this a bit more, too, because it squashes a *third*
solution which is similar to var but the other way round:

Dictionary<int,Dictionary<int,string>> foo = new(someParameter);

In other words, keep the type with the declaration rather than the
construction - assume any unqualified "new" is calling a constructor of
the class declared as the type of the variable. Doesn't work with
interfaces though...

 

[Daniel O'Connell [C# MVP]]

Whoops - I mean it's known at that *time*.

I mean that right at this point in code, from a reader's point of view, the
type is not defined explicitly. Using aliases means that the literal type of
the expression was defined before that point, using var it is defined after.
I don't think aliases solves the problem at all, as the reader is not going
to know the concrete type of the variable at all.

I meant to go into this a bit more, too, because it squashes a *third*
solution which is similar to var but the other way round:

Dictionary<int,Dictionary<int,string>> foo = new(someParameter);

In other words, keep the type with the declaration rather than the
construction - assume any unqualified "new" is calling a constructor of
the class declared as the type of the variable. Doesn't work with
interfaces though...

I can see where you are going here, but interfaces aren't always the answer,
and within method bodies I don't care that much. Dictionary<K,V> vs
IDictionary<K,V> within a single method is pretty irrelevent to me, its when
that reference is passed or returned.

As for using semantically meaningful names...I've never liked that. I'm
interested in the type to know the *type*, not to know the semantic use. The
semantic use is the domain of the variable name, not the type name, IMHO.

var ageToNameMap = ...;

achieves the same thing without a using alias

 

[Jon Skeet [C# MVP]]

I can see where you are going here, but interfaces aren't always the answer,
and within method bodies I don't care that much. Dictionary<K,V> vs
IDictionary<K,V> within a single method is pretty irrelevent to me, its when
that reference is passed or returned.

While interfaces aren't always the answer, I think it's a good habit to
get into to declare variables with only the information which is really
needed.

As for using semantically meaningful names...I've never liked that. I'm
interested in the type to know the *type*, not to know the semantic use. The
semantic use is the domain of the variable name, not the type name, IMHO.

var ageToNameMap = ...;

achieves the same thing without a using alias

So long as you only need one of them, of course... if you need two
maps, one of which is for students and one for teachers, for instance,
you'd either need to sacrifice some of the intent or have longer names.
If the name of the type gives intent too, there's less need to have it
all in the variable name.

A lot of this is typing as I think, I'll readily admit - it's as much a
gut instinct as anything else. I really just don't like not being able
to see a variable's type immediately from its declaration.

 

[Daniel O'Connell [C# MVP]]

So long as you only need one of them, of course... if you need two
maps, one of which is for students and one for teachers, for instance,
you'd either need to sacrifice some of the intent or have longer names.
If the name of the type gives intent too, there's less need to have it
all in the variable name.

Sure, and if you have two uses for Dictionary<K,V> with int, string
parameters, say an ageToNameMap and a idToNameMap, the alias approach can
fail you with lazy coders.

Neither one really fixes the problems, IMHO.

A lot of this is typing as I think, I'll readily admit - it's as much a
gut instinct as anything else. I really just don't like not being able
to see a variable's type immediately from its declaration.

Then why use aliases, which does not allow that, period. You have to look up
the type still.

 

[Jon Skeet [C# MVP]]

Sure, and if you have two uses for Dictionary<K,V> with int, string
parameters, say an ageToNameMap and a idToNameMap, the alias approach can
fail you with lazy coders.
True.

Neither one really fixes the problems, IMHO.

No - to be honest, I don't think any approach really does

Then why use aliases, which does not allow that, period. You have to look up
the type still.

Only if the type name doesn't give enough information, which I believe
it could. To be honest, I probably wouldn't actually do that - I'd
probably just stick with the long name in both places.

Only time will tell, but I'm going to stay wary of the whole business
for a while...

 

[Daniel O'Connell [C# MVP]]

Only if the type name doesn't give enough information, which I believe
it could. To be honest, I probably wouldn't actually do that - I'd
probably just stick with the long name in both places.

Only time will tell, but I'm going to stay wary of the whole business
for a while...

Ya, its going to take a while to adjust to, not to mention some good "best
practicies" and possibly some warnings.

I really dislike alot of the var stuff. var = 6; var=this; and var
=Method(); all seem horribly incomplete. It is basically just the anonymous
type and the complex generic where I initalize it on the same line that I
like it for. I would like the IDE to offer automatic type specification on
the fly, though. Something like::

var o = new Dictionary<int,int>();

transforms into

Dictionary<int,int> o = new Dictionary<int,int>();

as soon as I hit enter or whatever. It saves typing, keeps the langauge
consistent(since limiting var's usage could be construed as an
inconsistency), and keeps code written in the IDE easy to read without
making it harder to type.

 

[Jon Skeet [C# MVP]]

I really dislike alot of the var stuff. var = 6; var=this; and var
=Method(); all seem horribly incomplete. It is basically just the anonymous
type and the complex generic where I initalize it on the same line that I
like it for. I would like the IDE to offer automatic type specification on
the fly, though. Something like::

var o = new Dictionary<int,int>();

transforms into

Dictionary<int,int> o = new Dictionary<int,int>();

as soon as I hit enter or whatever. It saves typing, keeps the langauge
consistent(since limiting var's usage could be construed as an
inconsistency), and keeps code written in the IDE easy to read without
making it harder to type.

Right - now *that* I would have no problems with at all. I don't mind
IDEs speeding things up (and indeed in VS.NET I always feel very
limited compared with when I'm doing Java development in Eclipse) - so
long as the result is readable code

 

[Frans Bouma [C# MVP]]

much a >> > gut instinct as anything else. I really just don't like
not being able >> > to see a variable's type immediately from its
declaration.

Ya, its going to take a while to adjust to, not to mention some good
"best practicies" and possibly some warnings.

I really dislike alot of the var stuff. var = 6; var=this; and var
=Method(); all seem horribly incomplete. It is basically just the
anonymous type and the complex generic where I initalize it on the
same line that I like it for. I would like the IDE to offer automatic
type specification on the fly, though. Something like::

var o = new Dictionary<int,int>();

transforms into

Dictionary<int,int> o = new Dictionary<int,int>();

as soon as I hit enter or whatever. It saves typing, keeps the
langauge consistent(since limiting var's usage could be construed as
an inconsistency), and keeps code written in the IDE easy to read
without making it harder to type.

Now THAT's a wonderful idea!. I'd suggest you make a case for this
wonderful idea at the summit! They might find it a bit over the top
as every compilermaker always wants to avoid the point where the
compiler can actively update the sourcecode, but in this case it's
pretty OK IMHO.

FB

--

 

[Daniel O'Connell [C# MVP]]

Now THAT's a wonderful idea!. I'd suggest you make a case for this
wonderful idea at the summit! They might find it a bit over the top

I won't be at the summit, unfortunatly. I'm back in school, so its back to
poor student mode, .

However, if someone else wants to take it up, feel free. It is really not
much different than the expansions the IDE already does.

 

[david]

I would like the IDE to offer automatic type specification on
the fly, though. Something like::

var o = new Dictionary<int,int>();

transforms into

Dictionary<int,int> o = new Dictionary<int,int>();

as soon as I hit enter or whatever. It saves typing, keeps the langauge
consistent(since limiting var's usage could be construed as an
inconsistency), and keeps code written in the IDE easy to read without
making it harder to type.

But the IDE already does this for you, although it does it in the
opposite direction, which makes much more sense IMHO.

If I type

Dictionary<int,int> o = new

Intellisense will pop up with Dictionary<int,int> already selected. It
takes less typing than the var alternative.

 

[Daniel O'Connell [C# MVP]]

But the IDE already does this for you, although it does it in the
opposite direction, which makes much more sense IMHO.

If I type

Dictionary<int,int> o = new

Intellisense will pop up with Dictionary<int,int> already selected. It
takes less typing than the var alternative.

It only does it sometimes, if you use an interface or abstract class it
won't. Although it clearly is similar.

 

[david]

It only does it sometimes, if you use an interface or abstract class it
won't. Although it clearly is similar.

But var could never possibly work in that instance either.

var list = new List<int>();

There's no way that the IDE could know you wanted to declare an
IList here. And when it chose the wrong one, you'd be on the next
line and it would be a pain to correct it.

OTOH, I agree there's a lot of room for intellisense to improve here. If
I declare an interface, intellisense should show me classes that
implement it (I haven't played with VS2005 much, so it could be they're
better at that than they were).

 

[Christof Nordiek]

It only does it sometimes, if you use an interface or abstract class it
won't. Although it clearly is similar.

It does it in all cases where var x = new ... would work.

 

[Richard Blewett [DevelopMentor]]

I think what Daniel is saying is that if you wanted var to actaully be typed to an interface rather than the concrete type then the IDE can't do that for you

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

It only does it sometimes, if you use an interface or abstract class it
won't. Although it clearly is similar.

It does it in all cases where var x = new ... would work.



[microsoft.public.dotnet.languages.csharp]

 

[Guest]

For all I have read in this topic, I just didn't see any anonymous types.
The "var" keyword is just a way to delclare a variable with type inferrence.
The anonymous types are another cool stuff where you can define and
instanciate a new type (data oriented) in the same instruction. This could be
very usefull to get views on data:

var resultView = from newsItem in news,
author in authors
where newsItem.AuthorId == author.Id
select new(NewsTitle = newsItem.Title,
NewsContent = newsItem.Content, AuthorName = author.Name);

the last line create for each "row" returned by the query an instance of an
anonymous type. As this type is not named, you have no choice but use the
"var" keyword.

Sorry for my poor English...