|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Some thoughts on VB9http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp My thoughts: 1. Regarding Implicit types, I don't use type declaration for the benefits of performance. It's for the benefit of clarity of purpose when reading code. The first thing I do with neophyte developers is turn Option Strict On to help them understand why they do what they do. With this, I can't stop people from writing garbly gook. 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything, and there could be real beneifts to it. 3. Nullable types. I think this is a really good idea if it integrates with SQL Server well. 4. I think I will like the Query Comprehension features, because I think it makes understanding certain intents clearer. 5. "Because extension methods are intended mostly for library designers, Visual Basic does not offer direct language syntax support for declaring them." - This kind of comment has always bugged me, and probably rubs all VB developers who are serious about the language wrong. It reveals a "red headed stepchild" attitude toward the language, as if C# is the "real thing". If you really talked to VB developers in the field, I would imagine what they want more than anything is just a one to one feature set with C#. But this aside, I don't really like the extension concept because it feels too much like multiple inheritance and might have similar issues associated with it in terms of maintainability of code. 6. Nested functions I can see real benefits to, but it does make VB feel quite a bit like ML. But this could really go along way to making some things really easy to understand. 7. Relaxed Delgates. Dislike this for the same reason I don't like implicit type conversion. 8. Dynamic interfaces. Ditto. 9. Dynamic identifiers. More of the same. I guess my conclusion is I like some, but overall because of the destruction of clear typing, I have to give it a thumbs down. These sorts of things should be done sparingly in clear code, so sparingly that programmers should have to understand the intricacies of reflection before they are given a license to do them. I feel VB9 legislates bad habits and practices we gave up prior to VB.NET. My gut tells me that this is really all about upgrading the tremendous share of VB5 and VB6 users to .NET who so far not made the transition. I imagine upgrading a VB6 application to VB9 will be much simpler than any other .NET upgrade prior. But for those of us who have made the transition, I think the lack of typing is bad policy. It may simply be time for me to byte the bullet on curlies and semicolons -- Justin Weinberg MCAD/MCSD .NET >> this is really all about upgrading the tremendous share of VB5 and VB6 users to .NETNot to mention all the DotNet 2001, 2003, 2005 users who have already dished out thousands of $$$ trying to keep up with MS's "Developers!, Developers!, Developers!" non-backwards-compatible treadmill. Bob Lehmann "Justin Weinberg" <jweinberg@_spammyoff_mrgsoft.com> wrote in message http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.aspnews:uklfXglOGHA.1312@TK2MSFTNGP09.phx.gbl... > My thoughts on this.... > > Show quoteHide quote > > > My thoughts: > > 1. Regarding Implicit types, I don't use type declaration for the benefits > of performance. It's for the benefit of clarity of purpose when reading > code. The first thing I do with neophyte developers is turn Option Strict > On to help them understand why they do what they do. With this, I can't > stop people from writing garbly gook. > 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything, > and there could be real beneifts to it. > 3. Nullable types. I think this is a really good idea if it integrates > with SQL Server well. > 4. I think I will like the Query Comprehension features, because I think it > makes understanding certain intents clearer. > 5. "Because extension methods are intended mostly for library designers, > Visual Basic does not offer direct language syntax support for declaring > them." - This kind of comment has always bugged me, and probably rubs all VB > developers who are serious about the language wrong. It reveals a "red > headed stepchild" attitude toward the language, as if C# is the "real > thing". If you really talked to VB developers in the field, I would imagine > what they want more than anything is just a one to one feature set with C#. > But this aside, I don't really like the extension concept because it feels > too much like multiple inheritance and might have similar issues associated > with it in terms of maintainability of code. > 6. Nested functions I can see real benefits to, but it does make VB feel > quite a bit like ML. But this could really go along way to making some > things really easy to understand. > 7. Relaxed Delgates. Dislike this for the same reason I don't like > implicit type conversion. > 8. Dynamic interfaces. Ditto. > 9. Dynamic identifiers. More of the same. > > I guess my conclusion is I like some, but overall because of the > destruction of clear typing, I have to give it a thumbs down. These sorts > of things should be done sparingly in clear code, so sparingly that > programmers should have to understand the intricacies of reflection before > they are given a license to do them. I feel VB9 legislates bad habits and > practices we gave up prior to VB.NET. > > My gut tells me that this is really all about upgrading the tremendous share > of VB5 and VB6 users to .NET who so far not made the transition. I imagine > upgrading a VB6 application to VB9 will be much simpler than any other ..NET > upgrade prior. But for those of us who have made the transition, I think > the lack of typing is bad policy. It may simply be time for me to byte the > bullet on curlies and semicolons > > -- > Justin Weinberg > MCAD/MCSD .NET > > Seems to me MS is going in the wrong direction.... Accomodating the huge VB6
developing community is something they should have started with, and make things a bit stricter with every succeeding release. Show quoteHide quote "Justin Weinberg" <jweinberg@_spammyoff_mrgsoft.com> wrote in message news:uklfXglOGHA.1312@TK2MSFTNGP09.phx.gbl... > My thoughts on this.... > > http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp > > > My thoughts: > > 1. Regarding Implicit types, I don't use type declaration for the > benefits of performance. It's for the benefit of clarity of purpose when > reading code. The first thing I do with neophyte developers is turn > Option Strict On to help them understand why they do what they do. With > this, I can't stop people from writing garbly gook. > 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything, > and there could be real beneifts to it. > 3. Nullable types. I think this is a really good idea if it integrates > with SQL Server well. > 4. I think I will like the Query Comprehension features, because I think > it makes understanding certain intents clearer. > 5. "Because extension methods are intended mostly for library designers, > Visual Basic does not offer direct language syntax support for declaring > them." - This kind of comment has always bugged me, and probably rubs all > VB developers who are serious about the language wrong. It reveals a "red > headed stepchild" attitude toward the language, as if C# is the "real > thing". If you really talked to VB developers in the field, I would > imagine what they want more than anything is just a one to one feature set > with C#. But this aside, I don't really like the extension concept because > it feels too much like multiple inheritance and might have similar issues > associated with it in terms of maintainability of code. > 6. Nested functions I can see real benefits to, but it does make VB > feel quite a bit like ML. But this could really go along way to making > some things really easy to understand. > 7. Relaxed Delgates. Dislike this for the same reason I don't like > implicit type conversion. > 8. Dynamic interfaces. Ditto. > 9. Dynamic identifiers. More of the same. > > I guess my conclusion is I like some, but overall because of the > destruction of clear typing, I have to give it a thumbs down. These sorts > of things should be done sparingly in clear code, so sparingly that > programmers should have to understand the intricacies of reflection before > they are given a license to do them. I feel VB9 legislates bad habits and > practices we gave up prior to VB.NET. > > My gut tells me that this is really all about upgrading the tremendous > share of VB5 and VB6 users to .NET who so far not made the transition. I > imagine upgrading a VB6 application to VB9 will be much simpler than any > other .NET upgrade prior. But for those of us who have made the > transition, I think the lack of typing is bad policy. It may simply be > time for me to byte the bullet on curlies and semicolons > > -- > Justin Weinberg > MCAD/MCSD .NET > I agree. If the VS2005 TableAdapter (which harkens back to the Data Access
methodology of the 90's), and the My namespace, and Code Snippets tool doesn't entice them, there's no hope. I say forget them. VB doesn't need to get dumber. It needs to get smarter... and cooler- as I explain in another post in this thread. Very thoughtful analysis, Justin. I'm also against implicit types, and I
propose instead an autocomplete enhancement. The programmer types in dim xxx = "abc" and based on the initializer, autocomplete yields Dim xxx As String = "abc" In this way, the resulting source code will be understandable months later, and the programmer has yet another shortcut. Perhaps applicable to anonymous types as well. nice idea!
totally agree with justins analysis too! --guy-- Show quoteHide quote "AMercer" wrote: > Very thoughtful analysis, Justin. I'm also against implicit types, and I > propose instead an autocomplete enhancement. The programmer types in > dim xxx = "abc" > and based on the initializer, autocomplete yields > Dim xxx As String = "abc" > In this way, the resulting source code will be understandable months later, > and the programmer has yet another shortcut. Perhaps applicable to anonymous > types as well. > The problem VB has now is that Microsoft is puzzled about all the VB6
developers who haven't upgraded and their solution is starting to be a slightly desperate "give them whatever they want". The catch is that developers who haven't upgraded to .NET yet are likely to be the ones who most love the VB6 "let me forget to type in half the details and let the compiler sort it out" philosophy. So the result is that we already have implicit form instances (no, most VB6 developers don't know what that means, but they certainly know that they don't want to type one line to instantiate a form instance). In VB9 we'll have implicit variable types (again, most VB6 developers don't know what that means, but they certainly know that they don't want to have to think about variable types). I know that there are some intelligent argument for implicit types, but that is not what is driving the implicit variable types initiative at Microsoft. -- Show quoteHide quoteDavid Anton www.tangiblesoftwaresolutions.com Instant C#: VB to C# converter Instant VB: C# to VB converter Instant C++: C# to C++ converter & VB to C++ converter Instant J#: VB to J# converter "Justin Weinberg" wrote: > My thoughts on this.... > > http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp > > > My thoughts: > > 1. Regarding Implicit types, I don't use type declaration for the benefits > of performance. It's for the benefit of clarity of purpose when reading > code. The first thing I do with neophyte developers is turn Option Strict > On to help them understand why they do what they do. With this, I can't > stop people from writing garbly gook. > 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything, > and there could be real beneifts to it. > 3. Nullable types. I think this is a really good idea if it integrates > with SQL Server well. > 4. I think I will like the Query Comprehension features, because I think it > makes understanding certain intents clearer. > 5. "Because extension methods are intended mostly for library designers, > Visual Basic does not offer direct language syntax support for declaring > them." - This kind of comment has always bugged me, and probably rubs all VB > developers who are serious about the language wrong. It reveals a "red > headed stepchild" attitude toward the language, as if C# is the "real > thing". If you really talked to VB developers in the field, I would imagine > what they want more than anything is just a one to one feature set with C#. > But this aside, I don't really like the extension concept because it feels > too much like multiple inheritance and might have similar issues associated > with it in terms of maintainability of code. > 6. Nested functions I can see real benefits to, but it does make VB feel > quite a bit like ML. But this could really go along way to making some > things really easy to understand. > 7. Relaxed Delgates. Dislike this for the same reason I don't like > implicit type conversion. > 8. Dynamic interfaces. Ditto. > 9. Dynamic identifiers. More of the same. > > I guess my conclusion is I like some, but overall because of the > destruction of clear typing, I have to give it a thumbs down. These sorts > of things should be done sparingly in clear code, so sparingly that > programmers should have to understand the intricacies of reflection before > they are given a license to do them. I feel VB9 legislates bad habits and > practices we gave up prior to VB.NET. > > My gut tells me that this is really all about upgrading the tremendous share > of VB5 and VB6 users to .NET who so far not made the transition. I imagine > upgrading a VB6 application to VB9 will be much simpler than any other .NET > upgrade prior. But for those of us who have made the transition, I think > the lack of typing is bad policy. It may simply be time for me to byte the > bullet on curlies and semicolons > > -- > Justin Weinberg > MCAD/MCSD .NET > > > <SNIP>
> The catch is that developers who haven't upgraded to .NET yet are likely </SNIP>> to > be the ones who most love the VB6 "let me forget to type in half the > details > and let the compiler sort it out" philosophy. > > So the result is that we already have implicit form instances (no, most > VB6 > developers don't know what that means, but they certainly know that they > don't want to type one line to instantiate a form instance). In VB9 we'll > have implicit variable types (again, most VB6 developers don't know what > that > means, but they certainly know that they don't want to have to think about > variable types). "Most VB6 programmers" are not that dumb and/or messy... Sorry for the blanket statement - too rash.
I'll revise those statements to read "the VB6 developers who Microsoft seems to be listening to" instead of "most VB6 developers". It's the VB6 developers who are clamoring for implicit types who probably don't know the meanings of these terms. -- Show quoteHide quoteDavid Anton www.tangiblesoftwaresolutions.com Instant C#: VB to C# converter Instant VB: C# to VB converter Instant C++: C# to C++ converter & VB to C++ converter Instant J#: VB to J# converter "Martin" wrote: > <SNIP> > > The catch is that developers who haven't upgraded to .NET yet are likely > > to > > be the ones who most love the VB6 "let me forget to type in half the > > details > > and let the compiler sort it out" philosophy. > > > > So the result is that we already have implicit form instances (no, most > > VB6 > > developers don't know what that means, but they certainly know that they > > don't want to type one line to instantiate a form instance). In VB9 we'll > > have implicit variable types (again, most VB6 developers don't know what > > that > > means, but they certainly know that they don't want to have to think about > > variable types). > </SNIP> > > "Most VB6 programmers" are not that dumb and/or messy... > > > I agree. I think the VB community had sorted out all those "bad practices"
by the late 90's and early 2000 or so. But not all. I've met MANY genius (genius!) VB developers who wrote good (great!) code. However, because of VB.Classic's easy entry-level, there were many (many!) bad programmers who actually got well paying jobs and ended up producing a lot of the horrible crapola of VB programs that folks like me need to come in and upgrade/maintain/port. I think those guys formed about 75% of the *entire* VB developer base (from students to pros). Microsoft doesn't need to take a step back now. I think the learning curve of VB.NET is GOOD. It helps to weed out those kiddie-programmers who gave VB.Classic the rep it is still trying to live down to this day. Just my (admittedly condescending) 2c. Show quoteHide quote "David Anton" <DavidAn***@discussions.microsoft.com> wrote in message news:D2A0A2D9-2305-49FD-B8AA-74FF19F1318D@microsoft.com... > Sorry for the blanket statement - too rash. > I'll revise those statements to read "the VB6 developers who Microsoft > seems > to be listening to" instead of "most VB6 developers". > > It's the VB6 developers who are clamoring for implicit types who probably > don't know the meanings of these terms. > -- > David Anton > www.tangiblesoftwaresolutions.com > Instant C#: VB to C# converter > Instant VB: C# to VB converter > Instant C++: C# to C++ converter & VB to C++ converter > Instant J#: VB to J# converter > > > > "Martin" wrote: > >> <SNIP> >> > The catch is that developers who haven't upgraded to .NET yet are >> > likely >> > to >> > be the ones who most love the VB6 "let me forget to type in half the >> > details >> > and let the compiler sort it out" philosophy. >> > >> > So the result is that we already have implicit form instances (no, most >> > VB6 >> > developers don't know what that means, but they certainly know that >> > they >> > don't want to type one line to instantiate a form instance). In VB9 >> > we'll >> > have implicit variable types (again, most VB6 developers don't know >> > what >> > that >> > means, but they certainly know that they don't want to have to think >> > about >> > variable types). >> </SNIP> >> >> "Most VB6 programmers" are not that dumb and/or messy... >> >> >> I don't get the feeling MS is listening to any developers, but I'm sure some
bright mind in the marketing department thought of this all on his/her own. There are a whole bunch of serious, knowledgable and professional developers in VB6 who have created products over the years which can't be easily ported to VB.Net. For instance the upgrade analysis tool (the name slipped my mind) said about our flagship app that it would take a bit more than a year and a couple of $100K to port the app to VB.Net. And to make things worse it would mean that we would need to stop development for this app for that period of time. This is simply not an option. I don't know what MS was thinking when they created such an upgrade path, probably that there were only hobbyists toying with the language or so. Reading about the future releases of Windows shows that continuing in VB6 isn't an option either, so we are basically forced to invest this time and money into this upgrade. If MS would have listended to developers they would have never created such a nightmare scenario. Let me say that I do love VB2005 as language and development platform, it contains everything I have missed so much in VB6. But they should have offered a decent upgrade path (and useful help-documentation, I can't say that often enough, the provided documentation is absolutely sub-standard). Martin Show quoteHide quote "David Anton" <DavidAn***@discussions.microsoft.com> wrote in message news:D2A0A2D9-2305-49FD-B8AA-74FF19F1318D@microsoft.com... > Sorry for the blanket statement - too rash. > I'll revise those statements to read "the VB6 developers who Microsoft > seems > to be listening to" instead of "most VB6 developers". > > It's the VB6 developers who are clamoring for implicit types who probably > don't know the meanings of these terms. > -- > David Anton > www.tangiblesoftwaresolutions.com > Instant C#: VB to C# converter > Instant VB: C# to VB converter > Instant C++: C# to C++ converter & VB to C++ converter > Instant J#: VB to J# converter > > > > "Martin" wrote: > >> <SNIP> >> > The catch is that developers who haven't upgraded to .NET yet are >> > likely >> > to >> > be the ones who most love the VB6 "let me forget to type in half the >> > details >> > and let the compiler sort it out" philosophy. >> > >> > So the result is that we already have implicit form instances (no, most >> > VB6 >> > developers don't know what that means, but they certainly know that >> > they >> > don't want to type one line to instantiate a form instance). In VB9 >> > we'll >> > have implicit variable types (again, most VB6 developers don't know >> > what >> > that >> > means, but they certainly know that they don't want to have to think >> > about >> > variable types). >> </SNIP> >> >> "Most VB6 programmers" are not that dumb and/or messy... >> >> >> "Martin" <x@y.com> wrote in message Martin, when you say the Help Documentation is sub-standard, exactly what do news:ON7ms25OGHA.964@tk2msftngp13.phx.gbl... .. > > Let me say that I do love VB2005 as language and development platform, it > contains everything I have missed so much in VB6. But they should have > offered a decent upgrade path (and useful help-documentation, I can't say > that often enough, the provided documentation is absolutely sub-standard). > > Martin > you mean? Are you talking about help in upgrading VB6 code to VB2005 ? If that's the case, I agree. But, otherwise, I have found the new Help system in VB2005 to be very nice. In the first beta I tried, it was pretty bad, but, since it was a beta, I was not too suprised. But, the final product that I have ( Visual Studio 2005 Standard) , has very good help. And lots of good example code. Something that earlier versions were very short on. I really like the fact that the Help system not only looks for information from the local drive, but, also goes out and gets online information too. So far, I have been pretty pleased with VB2005 and the Help system. And I have been lucky that I do not have any legacy applications (VB6)that need porting to VB2005. ( although, I do have a current project in VB2003, that I plan to move to 2005) Anyway, I would be interested in what you find lacking in the new Help system. james When I want to look up information about something, I have to sift through
hundreds of pages of non-applicable garbage. The pages that do apply are probably auto-generated with some kind of robot that analyzes their source code. Try and look up information about how to assign shortcut keys to tabpage captions. In VB.COM it was pretty simple, you just put a ampersand in front of the character that serves as hotkey. This mechanism doesn't work anymore in VB2005, so I dive into the help-hell and try to find how to do this with search phrases like "tabpage shortcut key" and "tabcontrol shortcut key". None of the pages seems to give me any clue as to how to do this. Very well possible that it was there and I overlooked it, after the 30th page with non-applicable class structures I tend to get somewhat impatient and don't read the page thoroughly. The best help system was imho the one provided with VB5. There you looked up the control or whatever you needed, got a page with interesting general information and then links to properties, events, methods, examples, etc. Clear and to the point. In VB6 they provided us with MSDN, which still incorporated the old help documentation, you just had to search a bit harder. In my current VB2005 Team edition when I search for something I get litterally 100s of pages on MSDN online, a bunch of pages in the "Codezone Community", a few pages in "Questions" and most of the time 0 pages in Local Help. As of today my msdn online doesn't work anymore... "Search failed "The request failed with the error message: "-- "<html><head><title>Object moved</title></head><body> "<h2>Object moved to <a href=...... etc. Well, I'd say: Good riddens! Show quoteHide quote "james" <jjames700REMOV***@earthlink.net> wrote in message news:%23gU$Yl8OGHA.2124@TK2MSFTNGP14.phx.gbl... > > "Martin" <x@y.com> wrote in message > news:ON7ms25OGHA.964@tk2msftngp13.phx.gbl... > . >> >> Let me say that I do love VB2005 as language and development platform, it >> contains everything I have missed so much in VB6. But they should have >> offered a decent upgrade path (and useful help-documentation, I can't say >> that often enough, the provided documentation is absolutely >> sub-standard). >> >> Martin >> > > > Martin, when you say the Help Documentation is sub-standard, exactly what > do you mean? Are you talking about > help in upgrading VB6 code to VB2005 ? If that's the case, I agree. But, > otherwise, I have found the new Help > system in VB2005 to be very nice. In the first beta I tried, it was pretty > bad, but, since it was a beta, I was not > too suprised. But, the final product that I have ( Visual Studio 2005 > Standard) , has very good help. And lots of > good example code. Something that earlier versions were very short on. I > really like the fact that the Help system > not only looks for information from the local drive, but, also goes out > and gets online information too. So far, I have > been pretty pleased with VB2005 and the Help system. And I have been > lucky that I do not have any legacy applications > (VB6)that need porting to VB2005. ( although, I do have a current project > in VB2003, that I plan to move to 2005) > Anyway, I would be interested in what you find lacking in the new Help > system. > james > > I have it set to search Local First Then Online. And, I hate it when I press
F1 (the current right way; without highlighting the entire word) and the Help search instantly swtiches to Online Generic Mode Search because it can't find the topic in the local library. But, the topic IS in the library. Duh! Highlighting the word and hitting F1 triggers an even *more generic* search.... which is plain unintuitive in my opinion. This happens all the time... wish I could remember what the last topic was... but, it was something very simple that should not have triggered a catch-all search. Throw in the fact that you can't install the Library on a FileServer (as you've been able to do for the last 10 years) and VS2005 Help is PURE TRASH.... well, maybe that's a bit harsh. Let's just say that it's not an "improvement" over previous incarnations. I also agree that in terms of *VB* a better Help System has not been seen since the VB4 (and VB5? I went straight to VB6 from 4 so I don't know) days. It was clear and ACCURATE. VB6 MSDN Help wasn't great but at least it was exhaustive. VS2003's Help is neither great nor exhaustive. I get more helpful info from Google, Devx, and forums. Show quoteHide quote "Martin" <x@y.com> wrote in message news:%23d%23srZBPGHA.3888@TK2MSFTNGP12.phx.gbl... > When I want to look up information about something, I have to sift through > hundreds of pages of non-applicable garbage. The pages that do apply are > probably auto-generated with some kind of robot that analyzes their source > code. > > Try and look up information about how to assign shortcut keys to tabpage > captions. In VB.COM it was pretty simple, you just put a ampersand in > front of the character that serves as hotkey. This mechanism doesn't work > anymore in VB2005, so I dive into the help-hell and try to find how to do > this with search phrases like "tabpage shortcut key" and "tabcontrol > shortcut key". None of the pages seems to give me any clue as to how to do > this. Very well possible that it was there and I overlooked it, after the > 30th page with non-applicable class structures I tend to get somewhat > impatient and don't read the page thoroughly. > > The best help system was imho the one provided with VB5. There you looked > up the control or whatever you needed, got a page with interesting general > information and then links to properties, events, methods, examples, etc. > Clear and to the point. > > In VB6 they provided us with MSDN, which still incorporated the old help > documentation, you just had to search a bit harder. > > In my current VB2005 Team edition when I search for something I get > litterally 100s of pages on MSDN online, a bunch of pages in the "Codezone > Community", a few pages in "Questions" and most of the time 0 pages in > Local Help. > > As of today my msdn online doesn't work anymore... > > > "Search failed > "The request failed with the error message: > "-- > "<html><head><title>Object moved</title></head><body> > "<h2>Object moved to <a href=...... > > etc. > > Well, I'd say: Good riddens! > > > "james" <jjames700REMOV***@earthlink.net> wrote in message > news:%23gU$Yl8OGHA.2124@TK2MSFTNGP14.phx.gbl... >> >> "Martin" <x@y.com> wrote in message >> news:ON7ms25OGHA.964@tk2msftngp13.phx.gbl... >> . >>> >>> Let me say that I do love VB2005 as language and development platform, >>> it contains everything I have missed so much in VB6. But they should >>> have offered a decent upgrade path (and useful help-documentation, I >>> can't say that often enough, the provided documentation is absolutely >>> sub-standard). >>> >>> Martin >>> >> >> >> Martin, when you say the Help Documentation is sub-standard, exactly what >> do you mean? Are you talking about >> help in upgrading VB6 code to VB2005 ? If that's the case, I agree. But, >> otherwise, I have found the new Help >> system in VB2005 to be very nice. In the first beta I tried, it was >> pretty bad, but, since it was a beta, I was not >> too suprised. But, the final product that I have ( Visual Studio 2005 >> Standard) , has very good help. And lots of >> good example code. Something that earlier versions were very short on. I >> really like the fact that the Help system >> not only looks for information from the local drive, but, also goes out >> and gets online information too. So far, I have >> been pretty pleased with VB2005 and the Help system. And I have been >> lucky that I do not have any legacy applications >> (VB6)that need porting to VB2005. ( although, I do have a current project >> in VB2003, that I plan to move to 2005) >> Anyway, I would be interested in what you find lacking in the new Help >> system. >> james >> >> > > I hope James can find the topic in the Help file... Am dying to see how I
should do it. Show quoteHide quote "james" <jjames700REMOV***@earthlink.net> wrote in message news:%23gU$Yl8OGHA.2124@TK2MSFTNGP14.phx.gbl... > > "Martin" <x@y.com> wrote in message > news:ON7ms25OGHA.964@tk2msftngp13.phx.gbl... > . >> >> Let me say that I do love VB2005 as language and development platform, it >> contains everything I have missed so much in VB6. But they should have >> offered a decent upgrade path (and useful help-documentation, I can't say >> that often enough, the provided documentation is absolutely >> sub-standard). >> >> Martin >> > > > Martin, when you say the Help Documentation is sub-standard, exactly what > do you mean? Are you talking about > help in upgrading VB6 code to VB2005 ? If that's the case, I agree. But, > otherwise, I have found the new Help > system in VB2005 to be very nice. In the first beta I tried, it was pretty > bad, but, since it was a beta, I was not > too suprised. But, the final product that I have ( Visual Studio 2005 > Standard) , has very good help. And lots of > good example code. Something that earlier versions were very short on. I > really like the fact that the Help system > not only looks for information from the local drive, but, also goes out > and gets online information too. So far, I have > been pretty pleased with VB2005 and the Help system. And I have been > lucky that I do not have any legacy applications > (VB6)that need porting to VB2005. ( although, I do have a current project > in VB2003, that I plan to move to 2005) > Anyway, I would be interested in what you find lacking in the new Help > system. > james > > "Martin" <x@y.com> wrote in message Martin, all I can say is, it has worked for me , so far. I know that a news:exGRuzFPGHA.2012@TK2MSFTNGP14.phx.gbl... >I hope James can find the topic in the Help file... Am dying to see how I >should do it. > searh in Help does bring in a lot of hits, (nothing new, that has happened for years now) but, it seems to me , that the hits on the search are much better. I have yet to have to scroll thru every hit to find what I need. Usually the information is in the first few hits. The only thing that I would like to see added to the current help system, is a feature from Google, "Search within results". that is something I have wished for in Microsoft's Help system ( including MSDN's website) for a very long time. In fact, if they could include the advanced Search features like Google has in the Help system, that would be great. ( hey, there's an idea, Microsoft could license Google's Search engine..................not gonna happen!) james Ok, so where do I find how to put shortcut keys on tabpage titles?
Show quoteHide quote "james" <jjames700REMOV***@earthlink.net> wrote in message news:OjVlR4GPGHA.3896@TK2MSFTNGP15.phx.gbl... > > "Martin" <x@y.com> wrote in message > news:exGRuzFPGHA.2012@TK2MSFTNGP14.phx.gbl... >>I hope James can find the topic in the Help file... Am dying to see how I >>should do it. >> > > Martin, all I can say is, it has worked for me , so far. I know that a > searh in Help does bring in a lot of > hits, (nothing new, that has happened for years now) but, it seems to me , > that the hits on the search are > much better. I have yet to have to scroll thru every hit to find what I > need. Usually the information is in > the first few hits. The only thing that I would like to see added to the > current help system, is a feature > from Google, "Search within results". that is something I have wished for > in Microsoft's > Help system ( including MSDN's website) for a very long time. In fact, if > they could include the advanced > Search features like Google has in the Help system, that would be great. > ( hey, there's an idea, Microsoft > could license Google's Search engine..................not gonna happen!) > james > > Results of 10-second (literally!) research using Google vs 30-minute
research using VS' Help: Your answer found through Google Groups (not sure if it applies to VS2005). http://groups.google.com/group/microsoft.public.vb.controls/browse_thread/thread/8e87ebba9b4a0031/0ba1f0127acca2d1?lnk=st&q=dotnet+tabpage+accelerator&rnum=1#0ba1f0127acca2d1 A workaround also found through Google http://www.codeproject.com/vb/net/MnemonicTabControl.asp Try typing in "tabpage accelerator" in VS's Help and see if you get the same kind of results. VS2005's fancy "Online" did bring up similar results but not without showing a litany of irrelevant red-herrings first. Show quoteHide quote "Martin" <x@y.com> wrote in message news:%23W69pAHPGHA.536@TK2MSFTNGP09.phx.gbl... > Ok, so where do I find how to put shortcut keys on tabpage titles? > > "james" <jjames700REMOV***@earthlink.net> wrote in message > news:OjVlR4GPGHA.3896@TK2MSFTNGP15.phx.gbl... >> >> "Martin" <x@y.com> wrote in message >> news:exGRuzFPGHA.2012@TK2MSFTNGP14.phx.gbl... >>>I hope James can find the topic in the Help file... Am dying to see how I >>>should do it. >>> >> >> Martin, all I can say is, it has worked for me , so far. I know that a >> searh in Help does bring in a lot of >> hits, (nothing new, that has happened for years now) but, it seems to me >> , that the hits on the search are >> much better. I have yet to have to scroll thru every hit to find what I >> need. Usually the information is in >> the first few hits. The only thing that I would like to see added to the >> current help system, is a feature >> from Google, "Search within results". that is something I have wished >> for in Microsoft's >> Help system ( including MSDN's website) for a very long time. In fact, if >> they could include the advanced >> Search features like Google has in the Help system, that would be great. >> ( hey, there's an idea, Microsoft >> could license Google's Search engine..................not gonna happen!) >> james >> >> > > Well, as Martin's answer will show you,,,,,,,,,,,you cannot. At least not
without extending the tabcontrol and adding the function yourself. I did not say that the new Help was 100% better. And I didn't say it would be better for everyone. I said "I" like it and it works for "ME". I haven't had the need (yet) for shortcut keys on a tabcontrol. If I do, I now know where to look . (Martin's second link.........which I downloaded.) I have only said that "I" feel that the new Help is an improvement over the old system. And that is the way "I" feel about it. Like everyone else, I have an opinion and I expressed it. The new help system has worked better for me than the older system had................so far. I am sorry that it doesn't meet your needs. One thing for sure, I don't limit myself to just using the included help system. I also use Google's Groups Search and the MSDN website too. Unfortunately, with something as large and complex as Visual Basic and the Framework(s) have become, multiple help resources have become a must. james Show quoteHide quote "Martin" <x@y.com> wrote in message news:%23W69pAHPGHA.536@TK2MSFTNGP09.phx.gbl... > Ok, so where do I find how to put shortcut keys on tabpage titles? > > "james" <jjames700REMOV***@earthlink.net> wrote in message > news:OjVlR4GPGHA.3896@TK2MSFTNGP15.phx.gbl... >> >> "Martin" <x@y.com> wrote in message >> news:exGRuzFPGHA.2012@TK2MSFTNGP14.phx.gbl... >>>I hope James can find the topic in the Help file... Am dying to see how I >>>should do it. >>> >> >> Martin, all I can say is, it has worked for me , so far. I know that a >> searh in Help does bring in a lot of >> hits, (nothing new, that has happened for years now) but, it seems to me >> , that the hits on the search are >> much better. I have yet to have to scroll thru every hit to find what I >> need. Usually the information is in >> the first few hits. The only thing that I would like to see added to the >> current help system, is a feature >> from Google, "Search within results". that is something I have wished >> for in Microsoft's >> Help system ( including MSDN's website) for a very long time. In fact, if >> they could include the advanced >> Search features like Google has in the Help system, that would be great. >> ( hey, there's an idea, Microsoft >> could license Google's Search engine..................not gonna happen!) >> james >> >> > > Oh well, this turned out to be a bad example, because this is no longer
possible. But I'm glad to hear I'm not the only one with this opinion about the help documentation. Show quoteHide quote "james" <jjames700REMOV***@earthlink.net> wrote in message news:O7rOWsIPGHA.1360@TK2MSFTNGP10.phx.gbl... > Well, as Martin's answer will show you,,,,,,,,,,,you cannot. At least not > without extending the tabcontrol and adding the function yourself. I did > not say that the new Help was 100% better. And I didn't say it would be > better for everyone. > I said "I" like it and it works for "ME". I haven't had the need (yet) > for shortcut keys on a tabcontrol. If I do, I now know > where to look . (Martin's second link.........which I downloaded.) > I have only said that "I" feel that the new Help is an improvement over > the old system. And that is the way "I" feel about it. > Like everyone else, I have an opinion and I expressed it. The new help > system has worked better for me than the older > system had................so far. I am sorry that it doesn't meet your > needs. One thing for sure, I don't limit myself to just using > the included help system. I also use Google's Groups Search and the MSDN > website too. Unfortunately, with something as > large and complex as Visual Basic and the Framework(s) have become, > multiple help resources have become a must. > james > > "Martin" <x@y.com> wrote in message > news:%23W69pAHPGHA.536@TK2MSFTNGP09.phx.gbl... >> Ok, so where do I find how to put shortcut keys on tabpage titles? >> >> "james" <jjames700REMOV***@earthlink.net> wrote in message >> news:OjVlR4GPGHA.3896@TK2MSFTNGP15.phx.gbl... >>> >>> "Martin" <x@y.com> wrote in message >>> news:exGRuzFPGHA.2012@TK2MSFTNGP14.phx.gbl... >>>>I hope James can find the topic in the Help file... Am dying to see how >>>>I should do it. >>>> >>> >>> Martin, all I can say is, it has worked for me , so far. I know that a >>> searh in Help does bring in a lot of >>> hits, (nothing new, that has happened for years now) but, it seems to me >>> , that the hits on the search are >>> much better. I have yet to have to scroll thru every hit to find what I >>> need. Usually the information is in >>> the first few hits. The only thing that I would like to see added to >>> the current help system, is a feature >>> from Google, "Search within results". that is something I have wished >>> for in Microsoft's >>> Help system ( including MSDN's website) for a very long time. In fact, >>> if they could include the advanced >>> Search features like Google has in the Help system, that would be great. >>> ( hey, there's an idea, Microsoft >>> could license Google's Search engine..................not gonna happen!) >>> james >>> >>> >> >> > > A Document Outline for code that displays #regions as well as groups members
by type (Methods, Properties, etc). I saw at the Feature Request Labs that this is already in the pipeline but I'm not sure how many people have voted on it. Done right, this would be awesome. Smarter Code insertion. I don't use #Regions very much (I find them to be unwieldy given the lack of a Document Outline mentioned above) BUT I do like to keep related types of methods near each other in the file... like all my Property Accessors at the top and all my Event Handlers towards the end of the file. When I double click on a Control I'd like the code to be inserted near other event handlers.... not in the (seemingly) random way it's inserted now. Visual Attributes Editor. Attributes (or at least a common set of them) should show up in the Properties Toolbox (or something similar... like the way Code Snippets appear) when the cursor is positioned on the Method/Function/Property name line. I can never remember the exact syntax of the oodles of attributes that I often want to apply to a property. Refactoring in VB2005 is pretty lame. I like the right-click "Rename" symbol feature but that's pretty much the extent of refactoring in VB2005. The 3rd party free Refactor! Lite tool MS touts as a workaround is OK... but I'd like to see this as part of VB proper. Super-Smart Find. Regular Expressions is cool... but Find is still pretty dumb. I'd like to be able to search by Type- (Find Next "System.Windows.Forms.Control" reference). Probably no other thing will the give the VB community a slap in the *ss as a good set of Coding Standards Recommendations from MS. No, public Object Model recommendations is not enough. This would go a long way to helping VB achieve the same level of respect given to other development languages. It is for good reason that VB developers have a bad rep.... because we tend to write bad code because we feel like it and because we can. Open up two different applications from two different VB developers and you will see WILDLY different code standards.... this makes maintaining VB programs a NIGHTMARE.... and it is for sure a BIG reason corporations are trying to move away from VB and to C#. Show quoteHide quote "Justin Weinberg" <jweinberg@_spammyoff_mrgsoft.com> wrote in message news:uklfXglOGHA.1312@TK2MSFTNGP09.phx.gbl... > My thoughts on this.... > > http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp > > > My thoughts: > > 1. Regarding Implicit types, I don't use type declaration for the > benefits of performance. It's for the benefit of clarity of purpose when > reading code. The first thing I do with neophyte developers is turn > Option Strict On to help them understand why they do what they do. With > this, I can't stop people from writing garbly gook. > 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything, > and there could be real beneifts to it. > 3. Nullable types. I think this is a really good idea if it integrates > with SQL Server well. > 4. I think I will like the Query Comprehension features, because I think > it makes understanding certain intents clearer. > 5. "Because extension methods are intended mostly for library designers, > Visual Basic does not offer direct language syntax support for declaring > them." - This kind of comment has always bugged me, and probably rubs all > VB developers who are serious about the language wrong. It reveals a "red > headed stepchild" attitude toward the language, as if C# is the "real > thing". If you really talked to VB developers in the field, I would > imagine what they want more than anything is just a one to one feature set > with C#. But this aside, I don't really like the extension concept because > it feels too much like multiple inheritance and might have similar issues > associated with it in terms of maintainability of code. > 6. Nested functions I can see real benefits to, but it does make VB > feel quite a bit like ML. But this could really go along way to making > some things really easy to understand. > 7. Relaxed Delgates. Dislike this for the same reason I don't like > implicit type conversion. > 8. Dynamic interfaces. Ditto. > 9. Dynamic identifiers. More of the same. > > I guess my conclusion is I like some, but overall because of the > destruction of clear typing, I have to give it a thumbs down. These sorts > of things should be done sparingly in clear code, so sparingly that > programmers should have to understand the intricacies of reflection before > they are given a license to do them. I feel VB9 legislates bad habits and > practices we gave up prior to VB.NET. > > My gut tells me that this is really all about upgrading the tremendous > share of VB5 and VB6 users to .NET who so far not made the transition. I > imagine upgrading a VB6 application to VB9 will be much simpler than any > other .NET upgrade prior. But for those of us who have made the > transition, I think the lack of typing is bad policy. It may simply be > time for me to byte the bullet on curlies and semicolons > > -- > Justin Weinberg > MCAD/MCSD .NET > Oh yeah. And I totally agree with Justin's initial comments. I'd go further
and say Implicit types will be VB's death-knell. MS, I think, has gone insane in the last two years.... they're like a chicken without head not quite sure about what they should be doing. IMHO Soma Somasgar needs to goooooooo. There's so many more things they could be spending time to improve instead of this (like a good Visual Editor for Databinding rather than the cumbersome dropdown combo methods of today, better WebForm Designer, better more intuitive Visual Editor for Localization via Resources rather than bug-ridden unweildy combo dropdown editor we have today, etc etc). I could go on. P.S. I like LINQ and XLING though. That seems truly innovative. The only thing on my wish list for VB2005 are a couple of bug-fixes, maybe a
additional control or two (MDI Tabs perhaps) and most important: Decent help documentation! Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:Of$v69wOGHA.312@TK2MSFTNGP12.phx.gbl... > Oh yeah. And I totally agree with Justin's initial comments. I'd go > further and say Implicit types will be VB's death-knell. MS, I think, has > gone insane in the last two years.... they're like a chicken without head > not quite sure about what they should be doing. IMHO Soma Somasgar needs > to goooooooo. > > There's so many more things they could be spending time to improve instead > of this (like a good Visual Editor for Databinding rather than the > cumbersome dropdown combo methods of today, better WebForm Designer, > better more intuitive Visual Editor for Localization via Resources rather > than bug-ridden unweildy combo dropdown editor we have today, etc etc). > > I could go on. > > P.S. I like LINQ and XLING though. That seems truly innovative. > > -- > -C. Moya > www.cmoya.com > MDI Tabs. http://www.cflashsoft.com/progs/mdiwinman/ It's free and source
code included. Yeah, the Help contents... especially in VS2005 seems to have been written by robot... or simply dumped using a tool like NDoc. It's plain unhelpful. I find way more pertinent information using Google than using the gigabytes and gigabytes of VStudio Help and MSDN. Show quoteHide quote "Martin" <x@y.com> wrote in message news:u6UgwUyOGHA.3856@TK2MSFTNGP12.phx.gbl... > The only thing on my wish list for VB2005 are a couple of bug-fixes, maybe > a additional control or two (MDI Tabs perhaps) and most important: Decent > help documentation! > > "CMM" <cmm@nospam.com> wrote in message > news:Of$v69wOGHA.312@TK2MSFTNGP12.phx.gbl... >> Oh yeah. And I totally agree with Justin's initial comments. I'd go >> further and say Implicit types will be VB's death-knell. MS, I think, has >> gone insane in the last two years.... they're like a chicken without head >> not quite sure about what they should be doing. IMHO Soma Somasgar needs >> to goooooooo. >> >> There's so many more things they could be spending time to improve >> instead of this (like a good Visual Editor for Databinding rather than >> the cumbersome dropdown combo methods of today, better WebForm Designer, >> better more intuitive Visual Editor for Localization via Resources rather >> than bug-ridden unweildy combo dropdown editor we have today, etc etc). >> >> I could go on. >> >> P.S. I like LINQ and XLING though. That seems truly innovative. >> >> -- >> -C. Moya >> www.cmoya.com >> > > Yup, I've seen and downloaded that MDI tabs control, you did a great job
there. Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:OJVnbtyOGHA.2300@TK2MSFTNGP15.phx.gbl... > MDI Tabs. http://www.cflashsoft.com/progs/mdiwinman/ It's free and source > code included. > Yeah, the Help contents... especially in VS2005 seems to have been written > by robot... or simply dumped using a tool like NDoc. It's plain unhelpful. > I find way more pertinent information using Google than using the > gigabytes and gigabytes of VStudio Help and MSDN. > > -- > -C. Moya > www.cmoya.com > > "Martin" <x@y.com> wrote in message > news:u6UgwUyOGHA.3856@TK2MSFTNGP12.phx.gbl... >> The only thing on my wish list for VB2005 are a couple of bug-fixes, >> maybe a additional control or two (MDI Tabs perhaps) and most important: >> Decent help documentation! >> >> "CMM" <cmm@nospam.com> wrote in message >> news:Of$v69wOGHA.312@TK2MSFTNGP12.phx.gbl... >>> Oh yeah. And I totally agree with Justin's initial comments. I'd go >>> further and say Implicit types will be VB's death-knell. MS, I think, >>> has gone insane in the last two years.... they're like a chicken without >>> head not quite sure about what they should be doing. IMHO Soma Somasgar >>> needs to goooooooo. >>> >>> There's so many more things they could be spending time to improve >>> instead of this (like a good Visual Editor for Databinding rather than >>> the cumbersome dropdown combo methods of today, better WebForm Designer, >>> better more intuitive Visual Editor for Localization via Resources >>> rather than bug-ridden unweildy combo dropdown editor we have today, etc >>> etc). >>> >>> I could go on. >>> >>> P.S. I like LINQ and XLING though. That seems truly innovative. >>> >>> -- >>> -C. Moya >>> www.cmoya.com >>> >> >> > > It's a work in progress. The tab window switching works well I think. Now
I'm working on perfecting some of the other esoteric options like the Aux window.... as some of the properties conflict with each other (for instance AutoHide, doesn't resize the Aux Window when the WindowManagerPanel hides itself). If you have any comments or suggestions, by all means. Show quoteHide quote "Martin" <x@y.com> wrote in message news:em8MvEzOGHA.3516@TK2MSFTNGP15.phx.gbl... > Yup, I've seen and downloaded that MDI tabs control, you did a great job > there. > > > "CMM" <cmm@nospam.com> wrote in message > news:OJVnbtyOGHA.2300@TK2MSFTNGP15.phx.gbl... >> MDI Tabs. http://www.cflashsoft.com/progs/mdiwinman/ It's free and source >> code included. >> Yeah, the Help contents... especially in VS2005 seems to have been >> written by robot... or simply dumped using a tool like NDoc. It's plain >> unhelpful. I find way more pertinent information using Google than using >> the gigabytes and gigabytes of VStudio Help and MSDN. >> >> -- >> -C. Moya >> www.cmoya.com >> >> "Martin" <x@y.com> wrote in message >> news:u6UgwUyOGHA.3856@TK2MSFTNGP12.phx.gbl... >>> The only thing on my wish list for VB2005 are a couple of bug-fixes, >>> maybe a additional control or two (MDI Tabs perhaps) and most important: >>> Decent help documentation! >>> >>> "CMM" <cmm@nospam.com> wrote in message >>> news:Of$v69wOGHA.312@TK2MSFTNGP12.phx.gbl... >>>> Oh yeah. And I totally agree with Justin's initial comments. I'd go >>>> further and say Implicit types will be VB's death-knell. MS, I think, >>>> has gone insane in the last two years.... they're like a chicken >>>> without head not quite sure about what they should be doing. IMHO Soma >>>> Somasgar needs to goooooooo. >>>> >>>> There's so many more things they could be spending time to improve >>>> instead of this (like a good Visual Editor for Databinding rather than >>>> the cumbersome dropdown combo methods of today, better WebForm >>>> Designer, better more intuitive Visual Editor for Localization via >>>> Resources rather than bug-ridden unweildy combo dropdown editor we have >>>> today, etc etc). >>>> >>>> I could go on. >>>> >>>> P.S. I like LINQ and XLING though. That seems truly innovative. >>>> >>>> -- >>>> -C. Moya >>>> www.cmoya.com >>>> >>> >>> >> >> > > Agreed, very nice!!
james Show quoteHide quote "Martin" <x@y.com> wrote in message news:em8MvEzOGHA.3516@TK2MSFTNGP15.phx.gbl... > Yup, I've seen and downloaded that MDI tabs control, you did a great job > there. > > > "CMM" <cmm@nospam.com> wrote in message > news:OJVnbtyOGHA.2300@TK2MSFTNGP15.phx.gbl... >> MDI Tabs. http://www.cflashsoft.com/progs/mdiwinman/ It's free and source >> code included. >> Yeah, the Help contents... especially in VS2005 seems to have been >> written by robot... or simply dumped using a tool like NDoc. It's plain >> unhelpful. I find way more pertinent information using Google than using >> the gigabytes and gigabytes of VStudio Help and MSDN. >> >> -- >> -C. Moya >> www.cmoya.com >> Why thanks! I'm working on fixing the logic that deals with making changes
at runtime... like the AutoHide and Orientation clashing with each other and stuff. I'd like to get it real nice and super-stable so I can kinda leave it be for a while. ;-) Show quoteHide quote "james" <jjames700REMOV***@earthlink.net> wrote in message news:%23SUthQ1OGHA.3100@TK2MSFTNGP11.phx.gbl... > Agreed, very nice!! > james > > "Martin" <x@y.com> wrote in message > news:em8MvEzOGHA.3516@TK2MSFTNGP15.phx.gbl... >> Yup, I've seen and downloaded that MDI tabs control, you did a great job >> there. >> >> >> "CMM" <cmm@nospam.com> wrote in message >> news:OJVnbtyOGHA.2300@TK2MSFTNGP15.phx.gbl... >>> MDI Tabs. http://www.cflashsoft.com/progs/mdiwinman/ It's free and >>> source code included. >>> Yeah, the Help contents... especially in VS2005 seems to have been >>> written by robot... or simply dumped using a tool like NDoc. It's plain >>> unhelpful. I find way more pertinent information using Google than using >>> the gigabytes and gigabytes of VStudio Help and MSDN. >>> >>> -- >>> -C. Moya >>> www.cmoya.com >>> > > CMM wrote:
> Oh yeah. And I totally agree with Justin's initial comments. I'd go further Why will implicit local variable typing kill VB but not C# ?> and say Implicit types will be VB's death-knell. -- Larry Lard Replies to group please > Why will implicit local variable typing kill VB but not C# ? I don't know how to answer that without offending anyone.I fear in five years I'll be opening a big VB application at some bank and see a huge mess of code with nothing but implicit type declarations..... I'd go crazy! I'm sure Implicit Types have their place... like when used in conjunction with LINQ. But, VB developers are going to abuse it... I just know it. For the most part (and I know this may be an over-generalization) but C# developers are more disciplined and adhere to more structured sets of standards than do VB developers.... the language practically demands it. It's lack of background compile- and thus full real-time full syntax checking and full intellisense- (I won't even get into the reliance on delegates and non-intuitive event handling) just force you to be. VB may be easier to approach... easier to maintain... but, also A LOT easier to muck up. VB has a bad rep that it has just in the last four years begun to live down. I can smell that rep coming back. Show quoteHide quote "Larry Lard" <larryl***@hotmail.com> wrote in message news:1141040057.721226.309240@e56g2000cwe.googlegroups.com... > > CMM wrote: >> Oh yeah. And I totally agree with Justin's initial comments. I'd go >> further >> and say Implicit types will be VB's death-knell. > > Why will implicit local variable typing kill VB but not C# ? > > -- > Larry Lard > Replies to group please > i am afraid that you are right...
Show quoteHide quote "CMM" wrote: > > Why will implicit local variable typing kill VB but not C# ? > > I don't know how to answer that without offending anyone. > > I fear in five years I'll be opening a big VB application at some bank and > see a huge mess of code with nothing but implicit type declarations..... I'd > go crazy! I'm sure Implicit Types have their place... like when used in > conjunction with LINQ. But, VB developers are going to abuse it... I just > know it. > > For the most part (and I know this may be an over-generalization) but C# > developers are more disciplined and adhere to more structured sets of > standards than do VB developers.... the language practically demands it. > It's lack of background compile- and thus full real-time full syntax > checking and full intellisense- (I won't even get into the reliance on > delegates and non-intuitive event handling) just force you to be. VB may be > easier to approach... easier to maintain... but, also A LOT easier to muck > up. VB has a bad rep that it has just in the last four years begun to live > down. I can smell that rep coming back. > > > -- > -C. Moya > www.cmoya.com > "Larry Lard" <larryl***@hotmail.com> wrote in message > news:1141040057.721226.309240@e56g2000cwe.googlegroups.com... > > > > CMM wrote: > >> Oh yeah. And I totally agree with Justin's initial comments. I'd go > >> further > >> and say Implicit types will be VB's death-knell. > > > > Why will implicit local variable typing kill VB but not C# ? > > > > -- > > Larry Lard > > Replies to group please > > > > > "Justin Weinberg" <jweinberg@_spammyoff_mrgsoft.com> wrote in message
http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp
news:uklfXglOGHA.1312@TK2MSFTNGP09.phx.gbl... : : My thoughts on this.... : : I've taken an opportunity to review the material (thanx to the OP for the link) and I don't have the same reactions. First, I should note that these changes do not apply to VB only. There is also a link to the future of C# and I can't help but notice that the features being commented on here are being included in both languages. These features are changes at the framework level and are not changes to specific languages. At least, that's my take. Any down side to these changes will impact VB and C# equally and if VB code will become littered with bad code blocks, C# will be just as likely to have the same result. That said, I'm not so sure these changes will necessarily produce bad code. Here is the link to the C# document (Word .doc file) http://download.microsoft.com/download/9/5/0/9503e33e-fde6-4aed-b5d0-ffe749822f1b/csharp%203.0%20specification.doc : My thoughts: I don't see where implicit typed local variables is a bad idea. What's wrong: : 1. Regarding Implicit types, I don't use type declaration for the : benefits of performance. It's for the benefit of clarity of purpose when : reading code. The first thing I do with neophyte developers is turn : Option Strict On to help them understand why they do what they do. With : this, I can't stop people from writing garbly gook. with the following? Dim Title = "Dr." Dim GivenName = "Joseph" Dim OtherName = "" Dim FamilyName = "Bleaux" Dim NameSuffix = "Jr." Dim NickNames() = {"Doc", "Joe", "Junior"} Dim DateOfBirth = "UKNOWN" Dim DateOfDeath = "UKNOWN" Dim CauseOfDeath = "UNKNOWN" We are clearly defining 9 objects of type String (including an array of strings). As the documentation states, these are precisely equivalent to the following: Dim Title As String = "" Dim GivenName As String = "" Dim OtherName As String = "" Dim FamilyName As String = "" Dim NameSuffix As String = "" Dim NickNames() As String = {"Doc", "Joe", "Junior"} Dim DateOfBirth As String = "UNKNOWN" Dim DateOfDeath As String = "UNKNOWN" Dim CauseOfDeath As String = "UNKNOWN" In C#, the equivalent declaration would be: var Title = ""; var GivenName = ""; var OtherName = ""; var FamilyName = ""; var NameSuffix = ""; var NickNames = new String[] {"Doc", "Joe", "Junior"}; var DateOfBirth = "UKNOWN"; var DateOfDeath = "UKNOWN"; var CauseOfDeath = "UNKNOWN"; C# programmers will have a slightly more difficult time of things (they should be used to that by now) because var is not a keyword as Dim is in VB. If 'var' has been defined as a type and is in scope, then the compiler will be creating 9 objects of type var for the above instead of String objects (assuming that the above would compile at all). I find in interesting to note that this syntax causes C# to take on something of a VB look and feel: Dim Title = "" var Title = ""; Dim someObject = New SomeObjectType var someObject = new SomeObjectType(); Hmmmm... While I find the For / Next syntax to be a little odd visually, I still think it serves a handy purpose. As before, what is wrong with this? For Each Dim Item In MyCollection Console.WriteLine(Item.ToString()) Next Variable "Item" has a scope limited to the For block and whose type is clearly discernible. I have no use for the variable outside the For block (and couldn't access it if I did) and all I *really* need to know is how to use the object when I get it. Knowing the full name of the object doesn't affect any resulting code I write or the behavior that is generating. Normally, I'd have to have something along these lines For Each Item As MyCollectionItem In MyCollection Console.WriteLine(Item.ToString()) Next And finally as I understand it, type safety is not being violated here. In every case, objects are being assigned a specific type and implicit casts are still rejected. As far as I can tell, the following should be rejected by the compiler: Dim I = 0 Dim S = 2.0 I = S I'm defining an Integer (I) and a Single (S). I would expect the compiler to object to the third line in the same manner that it does today: Option Strict On disallows implicit conversions from 'Single' to 'Integer'. I = S ~ The objection to this syntax is not clear to me. How does explicitly defining the type in any of these expressions improve the code (either from the perspective of readability, type safety, or just plain good programming practices)? There is one related feature to this that I find particularly intriguing: the new object initializer syntax. I see this as a way to generate dynamic, custom purpose constructors by the consumer of a given class. I think this has a lot of potential. Returning to my earlier example, let's say I define the following pseudo-class: Public Class Person Public Property Title As String Public Property GivenName As String Public Property OtherName As String Public Property FamilyName As String Public Property Suffix As String Public Property NickNames() As String Public Property DateOfBirth As String Public Property DateOfDeath As String Public Property CauseOfDeath As String End Class I'm currently limited in how many different constructors I can expose. Perhaps: Sub New() Sub New(FamilyName As String) Sub New(FamilyName As String, GivenName As String) Etc. What I can't do is something like this: Sub New(FamilyName As String) Sub New(GivenName As String) So if I want to use this class and populate certain fields, I would need to do something along the following lines: Dim P As New Person("Joseph", "Bleaux") With P .Title = "Doctor" .Suffix = "Jr." .DateOfBirth = "1/2/1950" .DateOfDeath = "3/4/2006" .CauseOfDeath = "Cancer" End With With the new syntax, I can effectively define my own custom purpose constructor: Dim P As New Person( _ .Title = "Dr.", _ .GivenName = "Joseph", _ .FamilyName = "Bleaux", _ .Suffix = "Jr.", _ .DateOfBirth = "1/2/1950", _ .DateOfDeath = "3/4/2006", _ .CauseOfDeath = "Cancer") I like that. Show quoteHide quote : 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything, Here is the C# documentation commenting about the same thing:: and there could be real beneifts to it. : 3. Nullable types. I think this is a really good idea if it integrates : with SQL Server well. : 4. I think I will like the Query Comprehension features, because I think : it makes understanding certain intents clearer. : 5. "Because extension methods are intended mostly for library designers, : Visual Basic does not offer direct language syntax support for declaring : them." - This kind of comment has always bugged me, and probably rubs all : VB developers who are serious about the language wrong. It reveals a "red : headed stepchild" attitude toward the language, as if C# is the "real : thing". If you really talked to VB developers in the field, I would : imagine what they want more than anything is just a one to one feature set : with C#. Note Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible. Extension members of other kinds, such as properties, events, and operators, are being considered but are currently not supported. I don't see the bias against VB in this. If C# has slightly better support for this (and that's not clear to me), it isn't substantively so. Now it does appear that C# is getting some features missing from VB (if I'm reading the document correctly). One seems to be support for "Lambda expressions" which I gather are "anonymous methods". Both VB9 and C#3 are including support for "anonymous types" but that is evidently different from "anonymous methods". For whatever reason, C# will have this but VB won't (and perhaps I'm misreading the documentation - either way, I don't see where VB programmers are being patronized by these changes). Show quoteHide quote : But this aside, I don't really like the extension concept because it feels I don't believe this has anything to do MS with trying to code down to VB: too much like multiple inheritance and might have similar issues : associated with it in terms of maintainability of code. : 6. Nested functions I can see real benefits to, but it does make VB : feel quite a bit like ML. But this could really go along way to making : some things really easy to understand. : 7. Relaxed Delgates. Dislike this for the same reason I don't like : implicit type conversion. : 8. Dynamic interfaces. Ditto. : 9. Dynamic identifiers. More of the same. : : I guess my conclusion is I like some, but overall because of the : destruction of clear typing, I have to give it a thumbs down. These sorts : of things should be done sparingly in clear code, so sparingly that : programmers should have to understand the intricacies of reflection before : they are given a license to do them. I feel VB9 legislates bad habits and : practices we gave up prior to VB.NET. : : My gut tells me that this is really all about upgrading the tremendous : share of VB5 and VB6 users to .NET who so far not made the transition. I : imagine upgrading a VB6 application to VB9 will be much simpler than any : other .NET upgrade prior. But for those of us who have made the : transition, I think the lack of typing is bad policy. It may simply be : time for me to byte the bullet on curlies and semicolons : : -- : Justin Weinberg : MCAD/MCSD .NET programmers nor does it strike me as being targeted at getting VB5/6 programmers to make the move to VB.net. From what I can tell, both C# and VB are taking on virtually the same changes with pretty much the same end result. As I stated above, I really think these changes are framework driven and are not targeting any particular language. Ralf -- -- ---------------------------------------------------------- * ^~^ ^~^ * * _ {~ ~} {~ ~} _ * * /_``>*< >*<''_\ * * (\--_)++) (++(_--/) * ---------------------------------------------------------- There are no advanced students in Aikido - there are only competent beginners. There are no advanced techniques - only the correct application of basic principles. To answer your questions about implicit types:
While Strings might be obvious, and it might seem obvious that Dim s = 1 is an Integer. But, is it obvious that later in the method s / 2 will produce the results you might later expect if Option Explicit is Off or was removed by some other developer in the code's chain of custody? or that Dim s = 1.0 is a floating point single, floating point double, or a decimal type. or that Dim s = GetFormattedNumer() returns a stringbuilder and not a number or a string The use of it in For/Loops is even more ingratiating. From what I've read the C# community already has come out against overusing implicit type declarations. They're pretty good with not adopting bad habits. The fact that implicit types encourage laziness is something that has incredible potential for abuse. Show quoteHide quote "_AnonCoward" <abc***@uvwxyz.com> wrote in message news:UT1Nf.27332$915.4559@southeast.rr.com... > > "Justin Weinberg" <jweinberg@_spammyoff_mrgsoft.com> wrote in message > news:uklfXglOGHA.1312@TK2MSFTNGP09.phx.gbl... > : > : My thoughts on this.... > : > : > http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp > > > I've taken an opportunity to review the material (thanx to the OP for the > link) and I don't have the same reactions. > > > First, I should note that these changes do not apply to VB only. There is > also a link to the future of C# and I can't help but notice that the > features being commented on here are being included in both languages. > These > features are changes at the framework level and are not changes to > specific > languages. At least, that's my take. > > > Any down side to these changes will impact VB and C# equally and if VB > code > will become littered with bad code blocks, C# will be just as likely to > have > the same result. That said, I'm not so sure these changes will necessarily > produce bad code. > > > Here is the link to the C# document (Word .doc file) > > http://download.microsoft.com/download/9/5/0/9503e33e-fde6-4aed-b5d0-ffe749822f1b/csharp%203.0%20specification.doc > > > : My thoughts: > : > : 1. Regarding Implicit types, I don't use type declaration for the > : benefits of performance. It's for the benefit of clarity of purpose > when > : reading code. The first thing I do with neophyte developers is turn > : Option Strict On to help them understand why they do what they do. With > : this, I can't stop people from writing garbly gook. > > > I don't see where implicit typed local variables is a bad idea. What's > wrong > with the following? > > Dim Title = "Dr." > Dim GivenName = "Joseph" > Dim OtherName = "" > Dim FamilyName = "Bleaux" > Dim NameSuffix = "Jr." > Dim NickNames() = {"Doc", "Joe", "Junior"} > Dim DateOfBirth = "UKNOWN" > Dim DateOfDeath = "UKNOWN" > Dim CauseOfDeath = "UNKNOWN" > > > We are clearly defining 9 objects of type String (including an array of > strings). As the documentation states, these are precisely equivalent to > the > following: > > > Dim Title As String = "" > Dim GivenName As String = "" > Dim OtherName As String = "" > Dim FamilyName As String = "" > Dim NameSuffix As String = "" > Dim NickNames() As String = {"Doc", "Joe", "Junior"} > Dim DateOfBirth As String = "UNKNOWN" > Dim DateOfDeath As String = "UNKNOWN" > Dim CauseOfDeath As String = "UNKNOWN" > > > In C#, the equivalent declaration would be: > > > var Title = ""; > var GivenName = ""; > var OtherName = ""; > var FamilyName = ""; > var NameSuffix = ""; > var NickNames = new String[] {"Doc", "Joe", "Junior"}; > var DateOfBirth = "UKNOWN"; > var DateOfDeath = "UKNOWN"; > var CauseOfDeath = "UNKNOWN"; > > > C# programmers will have a slightly more difficult time of things (they > should be used to that by now) because var is not a keyword as Dim is in > VB. > If 'var' has been defined as a type and is in scope, then the compiler > will > be creating 9 objects of type var for the above instead of String objects > (assuming that the above would compile at all). I find in interesting to > note that this syntax causes C# to take on something of a VB look and > feel: > > Dim Title = "" > var Title = ""; > > Dim someObject = New SomeObjectType > var someObject = new SomeObjectType(); > > Hmmmm... > > > While I find the For / Next syntax to be a little odd visually, I still > think it serves a handy purpose. As before, what is wrong with this? > > > For Each Dim Item In MyCollection > Console.WriteLine(Item.ToString()) > Next > > > Variable "Item" has a scope limited to the For block and whose type is > clearly discernible. I have no use for the variable outside the For block > (and couldn't access it if I did) and all I *really* need to know is how > to > use the object when I get it. Knowing the full name of the object doesn't > affect any resulting code I write or the behavior that is generating. > Normally, I'd have to have something along these lines > > > For Each Item As MyCollectionItem In MyCollection > Console.WriteLine(Item.ToString()) > Next > > > And finally as I understand it, type safety is not being violated here. In > every case, objects are being assigned a specific type and implicit casts > are still rejected. As far as I can tell, the following should be rejected > by the compiler: > > > Dim I = 0 > Dim S = 2.0 > I = S > > > I'm defining an Integer (I) and a Single (S). I would expect the compiler > to > object to the third line in the same manner that it does today: > > Option Strict On disallows implicit conversions from 'Single' to > 'Integer'. > > I = S > ~ > > The objection to this syntax is not clear to me. How does explicitly > defining the type in any of these expressions improve the code (either > from > the perspective of readability, type safety, or just plain good > programming > practices)? > > > There is one related feature to this that I find particularly intriguing: > the new object initializer syntax. I see this as a way to generate > dynamic, > custom purpose constructors by the consumer of a given class. I think this > has a lot of potential. > > > Returning to my earlier example, let's say I define the following > pseudo-class: > > Public Class Person > Public Property Title As String > Public Property GivenName As String > Public Property OtherName As String > Public Property FamilyName As String > Public Property Suffix As String > Public Property NickNames() As String > Public Property DateOfBirth As String > Public Property DateOfDeath As String > Public Property CauseOfDeath As String > End Class > > > I'm currently limited in how many different constructors I can expose. > Perhaps: > > Sub New() > Sub New(FamilyName As String) > Sub New(FamilyName As String, GivenName As String) > > Etc. > > > What I can't do is something like this: > > Sub New(FamilyName As String) > Sub New(GivenName As String) > > > So if I want to use this class and populate certain fields, I would need > to > do something along the following lines: > > Dim P As New Person("Joseph", "Bleaux") > With P > .Title = "Doctor" > .Suffix = "Jr." > .DateOfBirth = "1/2/1950" > .DateOfDeath = "3/4/2006" > .CauseOfDeath = "Cancer" > End With > > With the new syntax, I can effectively define my own custom purpose > constructor: > > Dim P As New Person( _ > .Title = "Dr.", _ > .GivenName = "Joseph", _ > .FamilyName = "Bleaux", _ > .Suffix = "Jr.", _ > .DateOfBirth = "1/2/1950", _ > .DateOfDeath = "3/4/2006", _ > .CauseOfDeath = "Cancer") > > > I like that. > > > : 2. No conflcit on XLING. I may not use it, but it doesn't hurt > anything, > : and there could be real beneifts to it. > : 3. Nullable types. I think this is a really good idea if it integrates > : with SQL Server well. > : 4. I think I will like the Query Comprehension features, because I > think > : it makes understanding certain intents clearer. > : 5. "Because extension methods are intended mostly for library designers, > : Visual Basic does not offer direct language syntax support for declaring > : them." - This kind of comment has always bugged me, and probably rubs > all > : VB developers who are serious about the language wrong. It reveals a > "red > : headed stepchild" attitude toward the language, as if C# is the "real > : thing". If you really talked to VB developers in the field, I would > : imagine what they want more than anything is just a one to one feature > set > : with C#. > > > Here is the C# documentation commenting about the same thing: > > Note > > Extension methods are less discoverable and more limited in > functionality than instance methods. For those reasons, it is > recommended that extension methods be used sparingly and only > in situations where instance methods are not feasible or > possible. > > Extension members of other kinds, such as properties, events, > and operators, are being considered but are currently not > supported. > > > I don't see the bias against VB in this. If C# has slightly better support > for this (and that's not clear to me), it isn't substantively so. > > > Now it does appear that C# is getting some features missing from VB (if > I'm > reading the document correctly). One seems to be support for "Lambda > expressions" which I gather are "anonymous methods". Both VB9 and C#3 are > including support for "anonymous types" but that is evidently different > from > "anonymous methods". For whatever reason, C# will have this but VB won't > (and perhaps I'm misreading the documentation - either way, I don't see > where VB programmers are being patronized by these changes). > > > : But this aside, I don't really like the extension concept because it > feels > : too much like multiple inheritance and might have similar issues > : associated with it in terms of maintainability of code. > : 6. Nested functions I can see real benefits to, but it does make VB > : feel quite a bit like ML. But this could really go along way to making > : some things really easy to understand. > : 7. Relaxed Delgates. Dislike this for the same reason I don't like > : implicit type conversion. > : 8. Dynamic interfaces. Ditto. > : 9. Dynamic identifiers. More of the same. > : > : I guess my conclusion is I like some, but overall because of the > : destruction of clear typing, I have to give it a thumbs down. These > sorts > : of things should be done sparingly in clear code, so sparingly that > : programmers should have to understand the intricacies of reflection > before > : they are given a license to do them. I feel VB9 legislates bad habits > and > : practices we gave up prior to VB.NET. > : > : My gut tells me that this is really all about upgrading the tremendous > : share of VB5 and VB6 users to .NET who so far not made the transition. > I > : imagine upgrading a VB6 application to VB9 will be much simpler than any > : other .NET upgrade prior. But for those of us who have made the > : transition, I think the lack of typing is bad policy. It may simply be > : time for me to byte the bullet on curlies and semicolons > : > : -- > : Justin Weinberg > : MCAD/MCSD .NET > > > I don't believe this has anything to do MS with trying to code down to VB > programmers nor does it strike me as being targeted at getting VB5/6 > programmers to make the move to VB.net. From what I can tell, both C# and > VB > are taking on virtually the same changes with pretty much the same end > result. As I stated above, I really think these changes are framework > driven > and are not targeting any particular language. > > > Ralf > -- > -- > ---------------------------------------------------------- > * ^~^ ^~^ * > * _ {~ ~} {~ ~} _ * > * /_``>*< >*<''_\ * > * (\--_)++) (++(_--/) * > ---------------------------------------------------------- > There are no advanced students in Aikido - there are only > competent beginners. There are no advanced techniques - > only the correct application of basic principles. > > > >
Show quote
Hide quote
"CMM" <cmm@nospam.com> wrote in message <snip for space>news:%23TTqVpKPGHA.2624@TK2MSFTNGP12.phx.gbl... : : To answer your questions about implicit types: : While Strings might be obvious, and it might seem obvious that : Dim s = 1 : is an Integer. : But, is it obvious that later in the method : s / 2 will produce the results you might later expect if Option Explicit : is Off or was removed by some other developer in the code's chain of : custody? : or that : Dim s = 1.0 : is a floating point single, floating point double, or a decimal type. : or that : Dim s = GetFormattedNumer() : returns a stringbuilder and not a number or a string : : The use of it in For/Loops is even more ingratiating. : : From what I've read the C# community already has come out against : overusing implicit type declarations. They're pretty good with not : adopting bad habits. The fact that implicit types encourage laziness : is something that has incredible potential for abuse. : : : -- : -C. Moya : www.cmoya.com I've debated submitting this response as I'm really not adding anything to the discussion but I've come to the conclusion I agree that implicit types are not a good idea. I've just reach this conclusion for a different reason. You seem concerned that this will encourage laziness and lead to abuse. Perhaps, but I don't think that is all that great of a concern. Your statement that the "C# community already has come out against overusing implicit type declarations" implies (at least to me) that it isn't implicit typing that is the issue, but overuse of the mechanism. When all is said and done, the variable is being instantiated as a specific type with all the safeguards that entails. I may not know that "Dim s = GetFormattedNumer()" will set s to a StringBuilder object, but I am still constrained to using s identically as if I'd explicitly declared the variable type up front. That said, the more I play with this, the less I'm liking it. What struck me at first as being a convenient shorthand now seems more like a maintenance headache. I may know as the original coder what my intentions were for the following: Dim s = GetFormattedNumer() But as someone coming after the fact to maintain the code, it isn't nearly so obvious. In fact, I'll run into that problem even if I'm the original coder returning to the code six months later. I recognize now that every time I come across an implicit type statement, I will have to mentally discern the assignment type. It could cost me in time and additional bugs in the code if I misread the type. The following may be equivalent, but the second statement is much clearer: Dim I = 1 Dim I As Integer = 1 So, yeah - on further reflection, I agree that implicit typing is not that good of an idea after all. Ralf -- AA #2250 ------------------------------------------------------------- * ^~^ ^~^ * * _ {| |} {| |} _ * * /_``>*< >*<''_\ * * (\--_)++) (++(_--/) * ------------------------------------------------------------- Nature is the canvas of creation and evolution but one of the brushes. Religion points to the mind of God; Science reveals its unfolding. The subjective apprehends knowledge while the objective facilitates understanding. In all things, yin and yang - ever flowing, one into the other; always overtaking, always overtaken. I agree with you wholeheartedly... you hit the nail on the head much better
than I did. Indeed, the problem is overuse I think. Implicit typing while convenient in *some* situations, should not become a "standard practice." I am terrified that- in the VB community- it will become so. However, if you look at the LINQ stuff and how that works (IMO it's very B.A.S.I.C. "statement" - like.... which we've lost a lot of in VB.NET like "Open file For Input As Access... or many of the screen drawing statements) implicit typing is very useful and makes more sense. Show quoteHide quote "_AnonCoward" <abc***@uvwxyz.com> wrote in message news:1fZNf.51095$no3.31361@tornado.southeast.rr.com... > > "CMM" <cmm@nospam.com> wrote in message > news:%23TTqVpKPGHA.2624@TK2MSFTNGP12.phx.gbl... > : > : To answer your questions about implicit types: > : While Strings might be obvious, and it might seem obvious that > : Dim s = 1 > : is an Integer. > : But, is it obvious that later in the method > : s / 2 will produce the results you might later expect if Option Explicit > : is Off or was removed by some other developer in the code's chain of > : custody? > : or that > : Dim s = 1.0 > : is a floating point single, floating point double, or a decimal type. > : or that > : Dim s = GetFormattedNumer() > : returns a stringbuilder and not a number or a string > : > : The use of it in For/Loops is even more ingratiating. > : > : From what I've read the C# community already has come out against > : overusing implicit type declarations. They're pretty good with not > : adopting bad habits. The fact that implicit types encourage laziness > : is something that has incredible potential for abuse. > : > : > : -- > : -C. Moya > : www.cmoya.com > > > <snip for space> > > I've debated submitting this response as I'm really not adding anything to > the discussion but I've come to the conclusion I agree that implicit types > are not a good idea. I've just reach this conclusion for a different > reason. > > > You seem concerned that this will encourage laziness and lead to abuse. > Perhaps, but I don't think that is all that great of a concern. Your > statement that the "C# community already has come out against overusing > implicit type declarations" implies (at least to me) that it isn't > implicit > typing that is the issue, but overuse of the mechanism. When all is said > and > done, the variable is being instantiated as a specific type with all the > safeguards that entails. I may not know that "Dim s = GetFormattedNumer()" > will set s to a StringBuilder object, but I am still constrained to using > s > identically as if I'd explicitly declared the variable type up front. > > > That said, the more I play with this, the less I'm liking it. What struck > me > at first as being a convenient shorthand now seems more like a maintenance > headache. I may know as the original coder what my intentions were for the > following: > > > Dim s = GetFormattedNumer() > > > But as someone coming after the fact to maintain the code, it isn't nearly > so obvious. In fact, I'll run into that problem even if I'm the original > coder returning to the code six months later. I recognize now that every > time I come across an implicit type statement, I will have to mentally > discern the assignment type. It could cost me in time and additional bugs > in > the code if I misread the type. The following may be equivalent, but the > second statement is much clearer: > > > Dim I = 1 > Dim I As Integer = 1 > > > So, yeah - on further reflection, I agree that implicit typing is not that > good of an idea after all. > > > Ralf > -- > AA #2250 > ------------------------------------------------------------- > * ^~^ ^~^ * > * _ {| |} {| |} _ * > * /_``>*< >*<''_\ * > * (\--_)++) (++(_--/) * > ------------------------------------------------------------- > Nature is the canvas of creation and evolution but one of > the brushes. Religion points to the mind of God; Science > reveals its unfolding. The subjective apprehends knowledge > while the objective facilitates understanding. > > In all things, yin and yang - ever flowing, one into the > other; always overtaking, always overtaken. > > Not to offend anyone, but . . . a thousand years ago some ostensibly
intelligent people were having a similar discussion about how many angels could dance on the head of a pin. Don Show quoteHide quote On Fri, 3 Mar 2006 15:04:38 -0500, "CMM" <cmm@nospam.com> wrote: >I agree with you wholeheartedly... you hit the nail on the head much better >than I did. >Indeed, the problem is overuse I think. Implicit typing while convenient in >*some* situations, should not become a "standard practice." I am terrified >that- in the VB community- it will become so. > >However, if you look at the LINQ stuff and how that works (IMO it's very >B.A.S.I.C. "statement" - like.... which we've lost a lot of in VB.NET like >"Open file For Input As Access... or many of the screen drawing statements) >implicit typing is very useful and makes more sense. 
Other interesting topics
Set a text in a RowHeader cell
academic version [2003] at run time database connection Moving a project to a different location Raising CustomControl Events from within Class How to connect to MS Access.... X & Y within DataGridView Using 'Function Keys' In vb.net Newbie... Binary Formatter not suitable accross firewalls |
|||||||||||||||||||||||
