Type inference

[=?Utf-8?B?Z3V5?=]

What do people here think about VB2008 having the ability to infer type?
e.g you can now say Dim i=5
which will create i as an integer

Personally I do not like it as it is not consistent and may be confusing for
other devleopers to read.
Extreme example - what is the type of x below?
dim x= 4294967295

It also leads to inconsistency - sometimes you have to declare the type and
sometimes you dont.

I will be using Option Infer Off

Guy

[Armin Zingler]

"guy" <gu*@discussions.microsoft.comschrieb

What do people here think about VB2008 having the ability to infer
type? e.g you can now say Dim i=5
which will create i as an integer

Personally I do not like it as it is not consistent and may be
confusing for other devleopers to read.
Extreme example - what is the type of x below?
dim x= 4294967295

It also leads to inconsistency - sometimes you have to declare the
type and sometimes you dont.

I will be using Option Infer Off

I totally agree. Being aware of data types is much too basic and important
to deal with them superficially. (I wonder who asked for such a feature)
Armin

[Rory Becker]

What do people here think about VB2008 having the ability to infer

type?

I have to say I don't mind it.

e.g you can now say Dim i=5
which will create i as an integer

Personally I do not like it as it is not consistent and may be
confusing for other devleopers to read.

What's not consistent?

Extreme example - what is the type of x below?
dim x= 4294967295

Whatever numeric type is nessecary to store 4294967295.

I think it (Type inference) reduces noise on the page and I don't see that
we're loosing much by using it.

--
Rory

[Tom Shelton]

On Nov 19, 7:27 am, "Armin Zingler" <[e-mail]:

"guy" <[e-mail]

What do people here think about VB2008 having the ability to infer
type? e.g you can now say Dim i=5
which will create i as an integer

Personally I do not like it as it is not consistent and may be
confusing for other devleopers to read.
Extreme example - what is the type of x below?
dim x= 4294967295

It also leads to inconsistency - sometimes you have to declare the
type and sometimes you dont.

I will be using Option Infer Off

I totally agree. Being aware of data types is much too basic and important
to deal with them superficially. (I wonder who asked for such a feature)

Armin

Type Inference is necessary to support LINQ. It's the same reason it
is being added to C#. So, while I see a big potential for abuse - I
hope that it will be used judiciously.

--
Tom Shelton

[rowe_newsgroups]

On Nov 19, 9:27 am, "Armin Zingler" <[e-mail]:

"guy" <[e-mail]

What do people here think about VB2008 having the ability to infer
type? e.g you can now say Dim i=5
which will create i as an integer

Personally I do not like it as it is not consistent and may be
confusing for other devleopers to read.
Extreme example - what is the type of x below?
dim x= 4294967295

It also leads to inconsistency - sometimes you have to declare the
type and sometimes you dont.

I will be using Option Infer Off

I totally agree. Being aware of data types is much too basic and important
to deal with them superficially. (I wonder who asked for such a feature)

Armin

This worries me too, but as Tom pointed out it's necessary for LINQ.
It brings back painful memories of debugging inferred var types from
Javascript. Hopefully, since most people are already established in
the .NET world, it will not be used when it is not needed (i.e.
anywhere but LINQ).

I am curious, can you still declare an inferred variable with Option
Infer Off?

Something like:

Dim i as <Inferred>

That way we would retain the strongly typed error checking and still
have the LINQ functionality?

Thanks,

Seth Rowe

[=?Utf-8?B?Z3V5?=]

I am puzzled Tom, I am aware of various features being introduced to support
LINQ but I was not aware that this was one of them.

Guy

"Tom Shelton" wrote:

On Nov 19, 7:27 am, "Armin Zingler" <[e-mail]:

"guy" <[e-mail]

What do people here think about VB2008 having the ability to infer
type? e.g you can now say Dim i=5
which will create i as an integer

Personally I do not like it as it is not consistent and may be
confusing for other devleopers to read.
Extreme example - what is the type of x below?
dim x= 4294967295

It also leads to inconsistency - sometimes you have to declare the
type and sometimes you dont.

I will be using Option Infer Off

I totally agree. Being aware of data types is much too basic and important
to deal with them superficially. (I wonder who asked for such a feature)

Armin

Type Inference is necessary to support LINQ. It's the same reason it
is being added to C#. So, while I see a big potential for abuse - I
hope that it will be used judiciously.

--
Tom Shelton

[rowe_newsgroups]

On Nov 19, 10:05 am, guy <[e-mail]:

I am puzzled Tom, I am aware of various features being introduced to support
LINQ but I was not aware that this was one of them.

Guy

"Tom Shelton" wrote:

On Nov 19, 7:27 am, "Armin Zingler" <[e-mail]:

"guy" <[e-mail]

What do people here think about VB2008 having the ability to infer
type? e.g you can now say Dim i=5
which will create i as an integer

Personally I do not like it as it is not consistent and may be
confusing for other devleopers to read.
Extreme example - what is the type of x below?
dim x= 4294967295

It also leads to inconsistency - sometimes you have to declare the
type and sometimes you dont.

I will be using Option Infer Off

I totally agree. Being aware of data types is much too basic and important
to deal with them superficially. (I wonder who asked for such a feature)

Armin

Type Inference is necessary to support LINQ. It's the same reason it
is being added to C#. So, while I see a big potential for abuse - I
hope that it will be used judiciously.

--
Tom Shelton

Here's a link that might help you:

http://msdn.microsoft.com/msdnmag/is...asicInstincts/

Thanks,

Seth Rowe

[=?Utf-8?B?Z3V5?=]

Oh yes, it is because of Anonymous classes.

Thansk Seth I remember now.

Guy

"rowe_newsgroups" wrote:

On Nov 19, 10:05 am, guy <[e-mail]:

I am puzzled Tom, I am aware of various features being introduced to support
LINQ but I was not aware that this was one of them.

Guy

"Tom Shelton" wrote:

On Nov 19, 7:27 am, "Armin Zingler" <[e-mail]:
"guy" <[e-mail]

What do people here think about VB2008 having the ability to infer
type? e.g you can now say Dim i=5
which will create i as an integer

Personally I do not like it as it is not consistent and may be
confusing for other devleopers to read.
Extreme example - what is the type of x below?
dim x= 4294967295

It also leads to inconsistency - sometimes you have to declare the
type and sometimes you dont.

I will be using Option Infer Off

I totally agree. Being aware of data types is much too basic and important
to deal with them superficially. (I wonder who asked for such a feature)

Armin

Type Inference is necessary to support LINQ. It's the same reason it
is being added to C#. So, while I see a big potential for abuse - I
hope that it will be used judiciously.

--
Tom Shelton

Here's a link that might help you:

http://msdn.microsoft.com/msdnmag/is...asicInstincts/

Thanks,

Seth Rowe

[=?Utf-8?B?Z3V5?=]

"Rory Becker" wrote:

What do people here think about VB2008 having the ability to infer
type?

I have to say I don't mind it.

e.g you can now say Dim i=5
which will create i as an integer

Personally I do not like it as it is not consistent and may be
confusing for other devleopers to read.

What's not consistent?

Extreme example - what is the type of x below?
dim x= 4294967295

Whatever numeric type is nessecary to store 4294967295.

***exactly my point *** If you are looking at printed output do you want to
go and use Calculator to determine the datatype?

>
I think it (Type inference) reduces noise on the page and I don't see that
we're loosing much by using it.

--
Rory

Guy

[Rory Becker]

>>Extreme example - what is the type of x below?
dim x= 4294967295

Whatever numeric type is nessecary to store 4294967295.

***exactly my point *** If you are looking at printed output do you
want to go and use Calculator to determine the datatype?

Ok sure and granted you did ask "what is the type of x". But I guess my point
is why do you need to know. Studio/.Net will work it our for you.

Now I'll also grant that there are times when you need to constrain the data
by a type because of some requirement based on say database column size.

but aren't there cases where you simply don't care as long as it works.

I hate personally don't like the idea of dynamic types where x might be an
integer in one moment and then act like a strign the next. But this isn't
that. It's just allowing the IDE/.Net to work out what is neccesary in a
given case.

--
Rory

[Armin Zingler]

"Rory Becker" <Ro********@newsgroup.nospamschrieb

>

Extreme example - what is the type of x below?
dim x= 4294967295
Whatever numeric type is nessecary to store 4294967295.
>

***exactly my point *** If you are looking at printed output do
you want to go and use Calculator to determine the datatype?

Ok sure and granted you did ask "what is the type of x". But I guess
my point is why do you need to know. Studio/.Net will work it our
for you.

*You* must know the type. How can you handle something if you don't know
what it is?

Now I'll also grant that there are times when you need to constrain
the data by a type because of some requirement based on say database
column size.

but aren't there cases where you simply don't care as long as it
works.

No. While programming, "don't care" is never good.

dim x = integer.maxvalue
x += 1

"Why doesn't it work? x is a 'numeric value'." That's what happens if you
don't care.

I hate personally don't like the idea of dynamic types where x might
be an integer in one moment and then act like a strign the next. But
this isn't that. It's just allowing the IDE/.Net to work out what is
neccesary in a given case.

In my understanding, reserving memory is one thing, filling it afterwards is
the other one. Therefore, it is impossible to do the 1st by doing the 2nd.
The line gives the impression that the assignment implicitly reserves the
memory. That's simply wrong.
Armin

[rowe_newsgroups]

What the hell

I don't think I've ever heard, err read, you swear before. Not sure
why that struck me funny...

:-)

Thanks,

Seth Rowe

[=?Utf-8?B?Z3V5?=]

"Rory Becker" wrote:

>

>Extreme example - what is the type of x below?
dim x= 4294967295
Whatever numeric type is nessecary to store 4294967295.

***exactly my point *** If you are looking at printed output do you
want to go and use Calculator to determine the datatype?

Ok sure and granted you did ask "what is the type of x". But I guess my point
is why do you need to know. Studio/.Net will work it our for you.

Now I'll also grant that there are times when you need to constrain the data
by a type because of some requirement based on say database column size.

but aren't there cases where you simply don't care as long as it works.

because if you do dim i=3 expecting a byte (you will get an integer) and
stick it in an array it will consume four times the ram that you had expected

Guy

I hate personally don't like the idea of dynamic types where x might be an
integer in one moment and then act like a strign the next. But this isn't
that. It's just allowing the IDE/.Net to work out what is neccesary in a
given case.

--
Rory