Type inference

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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
 
guy said:
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
Click to expand...

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
 
What do people here think about VB2008 having the ability to infer
type?
Click to expand...

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.
Click to expand...

What's not consistent?

Extreme example - what is the type of x below?
dim x= 4294967295
Click to expand...

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.
 
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
Click to expand...

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.
 
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
Click to expand...

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
 
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
 
Oh yes, it is because of Anonymous classes.

Thansk Seth I remember now.

Guy

rowe_newsgroups said:
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 said:
"guy" <[email protected]> schrieb
Click to expand...
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
Click to expand...
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
Click to expand...
It also leads to inconsistency - sometimes you have to declare the
type and sometimes you dont.
Click to expand...
I will be using Option Infer Off
Click to expand...
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)

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.
Click to expand...
Click to expand...

Here's a link that might help you:

http://msdn.microsoft.com/msdnmag/issues/07/10/BasicInstincts/

Thanks,

Seth Rowe
Click to expand...
 
Rory Becker said:
I have to say I don't mind it.


What's not consistent?



Whatever numeric type is nessecary to store 4294967295.
Click to expand...

***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.
Click to expand...
Guy
 
***exactly my point *** If you are looking at printed output do you
want to go and use Calculator to determine the datatype?
Click to expand...

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 Becker said:
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.
Click to expand...

*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.
Click to expand...

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.
Click to expand...

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
 
Armin,

I remember me that we had in past long discussions about the use of Option
Strict off.

I have to say, you were right, however this is the answer to it, to do it
with direct binding. A long time wish of me as you would know.

What the hell is proofing a sample as dim a=4294967295. If it needs to be
exact, then use it exact, that gives then even more documentative
information.

And I am very strict in this.

:-)

Cor
 
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
 
Rory Becker said:
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.
Click to expand...
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
 
Back
Top