|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Type inferenceWhat 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
Show quote
Hide quote
"guy" <g**@discussions.microsoft.com> schrieb I totally agree. Being aware of data types is much too basic and important> 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 to deal with them superficially. (I wonder who asked for such a feature) Armin
Show quote
Hide quote
On Nov 19, 7:27 am, "Armin Zingler" <az.nos***@freenet.de> wrote: Type Inference is necessary to support LINQ. It's the same reason it> "guy" <g***@discussions.microsoft.com> schrieb > > > 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 is being added to C#. So, while I see a big potential for abuse - I hope that it will be used judiciously. -- Tom Shelton 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 Show quoteHide quote "Tom Shelton" wrote: > On Nov 19, 7:27 am, "Armin Zingler" <az.nos***@freenet.de> wrote: > > "guy" <g***@discussions.microsoft.com> schrieb > > > > > 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 > On Nov 19, 10:05 am, guy <g***@discussions.microsoft.com> wrote:
Show quoteHide quote > I am puzzled Tom, I am aware of various features being introduced to support Here's a link that might help you:> LINQ but I was not aware that this was one of them. > > Guy > > "Tom Shelton" wrote: > > On Nov 19, 7:27 am, "Armin Zingler" <az.nos***@freenet.de> wrote: > > > "guy" <g***@discussions.microsoft.com> schrieb > > > > > 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 http://msdn.microsoft.com/msdnmag/issues/07/10/BasicInstincts/ Thanks, Seth Rowe Oh yes, it is because of Anonymous classes.
Thansk Seth I remember now. Guy Show quoteHide quote "rowe_newsgroups" wrote: > On Nov 19, 10:05 am, guy <g***@discussions.microsoft.com> wrote: > > 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" <az.nos***@freenet.de> wrote: > > > > "guy" <g***@discussions.microsoft.com> schrieb > > > > > > > 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/issues/07/10/BasicInstincts/ > > Thanks, > > Seth Rowe >
Show quote
Hide quote
On Nov 19, 9:27 am, "Armin Zingler" <az.nos***@freenet.de> wrote: This worries me too, but as Tom pointed out it's necessary for LINQ.> "guy" <g***@discussions.microsoft.com> schrieb > > > 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 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 > What do people here think about VB2008 having the ability to infer I have to say I don't mind it.> type? > e.g you can now say Dim i=5 What's not consistent?> 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? Whatever numeric type is nessecary to store 4294967295.> dim x= 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
Show quote
Hide quote
"Rory Becker" wrote: ***exactly my point *** If you are looking at printed output do you want to > > 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. go and use Calculator to determine the datatype? Show quoteHide quote > > 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 >>> Extreme example - what is the type of x below? Ok sure and granted you did ask "what is the type of x". But I guess my point >>> 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? 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 "Rory Becker" <RoryBecker@newsgroup.nospam> schrieb *You* must know the type. How can you handle something if you don't know> > > > > 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. what it is? > Now I'll also grant that there are times when you need to constrain No. While programming, "don't care" is never good.> 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. 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 In my understanding, reserving memory is one thing, filling it afterwards is> 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. 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 surewhy that struck me funny... :-) Thanks,Seth Rowe
Show quote
Hide quote
"Rory Becker" wrote: because if you do dim i=3 expecting a byte (you will get an integer) and > > >>> 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. > stick it in an array it will consume four times the ram that you had expected Guy Show quoteHide quote > 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 > > > 
Other interesting topics
Read very large file in bytearray and upload to MSSQL
VB calling DLL only with _stdcall? Getting a subset of DataRows from a DataTable setdatabinding Web Server Read/Write Problem with ToolStripTextBox Insert smaller images into one Image object Edit And Continue doesn't work :-( Form - controls is placed different on Vista than in XP design pattern vb.net |
|||||||||||||||||||||||
