|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
CStr() vs. .ToString()Book I am reading says that Cstr() is best method for efficency and safety
however it doesnt compare that method of the .ToString() method. Which is best. Thanks IMHO (and this has been debated for quite some time now), you should view
all of the old "data-type" specific functions as legacy functions and no longer use them. Instead, use the more object-oriented methods of a type. CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or .ToString All date/time functions would be replaced with methods and properties of the Date class All string functions would be replaced with methods and properties of the String class. et all. Show quoteHide quote "Sean" <S***@discussions.microsoft.com> wrote in message news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... > Book I am reading says that Cstr() is best method for efficency and safety > however it doesnt compare that method of the .ToString() method. > > Which is best. > > Thanks > > both points of view are valid, however i use the vb string methods as the
compiler makes optimzations that can improve performance over the native .Net methods, also i find the vb methods read better. cheers guy Show quoteHide quote "Scott M." wrote: > IMHO (and this has been debated for quite some time now), you should view > all of the old "data-type" specific functions as legacy functions and no > longer use them. Instead, use the more object-oriented methods of a type. > > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or .ToString > All date/time functions would be replaced with methods and properties of the > Date class > All string functions would be replaced with methods and properties of the > String class. > > et all. > > > "Sean" <S***@discussions.microsoft.com> wrote in message > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... > > Book I am reading says that Cstr() is best method for efficency and safety > > however it doesnt compare that method of the .ToString() method. > > > > Which is best. > > > > Thanks > > > > > > > for my clarification
..ToString() = native .Net methods CStr() = vb String methods? from my understanding in the book I am reading Cstr() etc is the perfered way however it doesnt address .ToString() Show quoteHide quote "guy" wrote: > both points of view are valid, however i use the vb string methods as the > compiler makes optimzations that can improve performance over the native .Net > methods, also i find the vb methods read better. > > cheers > > guy > > "Scott M." wrote: > > > IMHO (and this has been debated for quite some time now), you should view > > all of the old "data-type" specific functions as legacy functions and no > > longer use them. Instead, use the more object-oriented methods of a type. > > > > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or .ToString > > All date/time functions would be replaced with methods and properties of the > > Date class > > All string functions would be replaced with methods and properties of the > > String class. > > > > et all. > > > > > > "Sean" <S***@discussions.microsoft.com> wrote in message > > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... > > > Book I am reading says that Cstr() is best method for efficency and safety > > > however it doesnt compare that method of the .ToString() method. > > > > > > Which is best. > > > > > > Thanks > > > > > > > > > > > > "guy" <g**@discussions.microsoft.com> wrote in message The VB 6.0 way are not methods, they are functions. The .NET way are object news:2199BA10-0B41-4D7D-B7AF-F34D469457BD@microsoft.com... > both points of view are valid, however i use the vb string methods as the > compiler makes optimzations that can improve performance over the native > .Net > methods, also i find the vb methods read better. methods. The VB.NET compiler does NOT optimize the VB 6.0 functions to work BETTER than the natvie .NET object methods. To answer your question, ToString would be my suggestion, rather than CStr(). ToString is a method of the Object Type, and since all classes inherit from Object, all objects have this method. Show quoteHide quote > > cheers > > guy > > "Scott M." wrote: > >> IMHO (and this has been debated for quite some time now), you should view >> all of the old "data-type" specific functions as legacy functions and no >> longer use them. Instead, use the more object-oriented methods of a >> type. >> >> CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or >> .ToString >> All date/time functions would be replaced with methods and properties of >> the >> Date class >> All string functions would be replaced with methods and properties of the >> String class. >> >> et all. >> >> >> "Sean" <S***@discussions.microsoft.com> wrote in message >> news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... >> > Book I am reading says that Cstr() is best method for efficency and >> > safety >> > however it doesnt compare that method of the .ToString() method. >> > >> > Which is best. >> > >> > Thanks >> > >> > >> >> >> Nonsense. CStr is not some VB6 (better term is VB.Classic) legacy thing....
in .NET it's just a convenience wrapper around CType... which when used to cast to a string is simply a wrapper around the object's ToString("G"). I personally tend to use ToString() as well on my own strings.... but when I'm handling strings that come from functions that I know might return nulls I'd tend to use CStr().... it's the same exact thing as typing out all your "If bla Is Nothing" code that I'm sure litters your nasty code (or maybe it doesn't.... which is just as bad). P.S. I'm not sure you know what a Method vs. a Function vs. a Statement is... at least judging from the poppycock vomited in your post. Show quoteHide quote "Scott M." <s-mar@nospam.nospam> wrote in message news:eBEJ1bNNGHA.2816@TK2MSFTNGP15.phx.gbl... > > "guy" <g**@discussions.microsoft.com> wrote in message > news:2199BA10-0B41-4D7D-B7AF-F34D469457BD@microsoft.com... >> both points of view are valid, however i use the vb string methods as the >> compiler makes optimzations that can improve performance over the native >> .Net >> methods, also i find the vb methods read better. > > The VB 6.0 way are not methods, they are functions. The .NET way are > object methods. The VB.NET compiler does NOT optimize the VB 6.0 > functions to work BETTER than the natvie .NET object methods. > > To answer your question, ToString would be my suggestion, rather than > CStr(). ToString is a method of the Object Type, and since all classes > inherit from Object, all objects have this method. > > >> >> cheers >> >> guy >> >> "Scott M." wrote: >> >>> IMHO (and this has been debated for quite some time now), you should >>> view >>> all of the old "data-type" specific functions as legacy functions and no >>> longer use them. Instead, use the more object-oriented methods of a >>> type. >>> >>> CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or >>> .ToString >>> All date/time functions would be replaced with methods and properties of >>> the >>> Date class >>> All string functions would be replaced with methods and properties of >>> the >>> String class. >>> >>> et all. >>> >>> >>> "Sean" <S***@discussions.microsoft.com> wrote in message >>> news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... >>> > Book I am reading says that Cstr() is best method for efficency and >>> > safety >>> > however it doesnt compare that method of the .ToString() method. >>> > >>> > Which is best. >>> > >>> > Thanks >>> > >>> > >>> >>> >>> > > I think you better read your own post. CStr() is a built-in function of the
VB 6 language. It is not a method. ToString is a method of the Object type (which all classes in .NET derive from). So, I'm not sure why you feel the need to call this poppycock and suggest that I don't know what a function vs. a method is. As for which is better... As I said in my first post, it is a matter of choice and I prefer the more object-oriented ToString object method. Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:edKgVRPNGHA.1608@TK2MSFTNGP11.phx.gbl... > Nonsense. CStr is not some VB6 (better term is VB.Classic) legacy > thing.... in .NET it's just a convenience wrapper around CType... which > when used to cast to a string is simply a wrapper around the object's > ToString("G"). I personally tend to use ToString() as well on my own > strings.... but when I'm handling strings that come from functions that I > know might return nulls I'd tend to use CStr().... it's the same exact > thing as typing out all your "If bla Is Nothing" code that I'm sure > litters your nasty code (or maybe it doesn't.... which is just as bad). > > P.S. I'm not sure you know what a Method vs. a Function vs. a Statement > is... at least judging from the poppycock vomited in your post. > > -- > -C. Moya > www.cmoya.com > "Scott M." <s-mar@nospam.nospam> wrote in message > news:eBEJ1bNNGHA.2816@TK2MSFTNGP15.phx.gbl... >> >> "guy" <g**@discussions.microsoft.com> wrote in message >> news:2199BA10-0B41-4D7D-B7AF-F34D469457BD@microsoft.com... >>> both points of view are valid, however i use the vb string methods as >>> the >>> compiler makes optimzations that can improve performance over the native >>> .Net >>> methods, also i find the vb methods read better. >> >> The VB 6.0 way are not methods, they are functions. The .NET way are >> object methods. The VB.NET compiler does NOT optimize the VB 6.0 >> functions to work BETTER than the natvie .NET object methods. >> >> To answer your question, ToString would be my suggestion, rather than >> CStr(). ToString is a method of the Object Type, and since all classes >> inherit from Object, all objects have this method. >> >> >>> >>> cheers >>> >>> guy >>> >>> "Scott M." wrote: >>> >>>> IMHO (and this has been debated for quite some time now), you should >>>> view >>>> all of the old "data-type" specific functions as legacy functions and >>>> no >>>> longer use them. Instead, use the more object-oriented methods of a >>>> type. >>>> >>>> CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or >>>> .ToString >>>> All date/time functions would be replaced with methods and properties >>>> of the >>>> Date class >>>> All string functions would be replaced with methods and properties of >>>> the >>>> String class. >>>> >>>> et all. >>>> >>>> >>>> "Sean" <S***@discussions.microsoft.com> wrote in message >>>> news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... >>>> > Book I am reading says that Cstr() is best method for efficency and >>>> > safety >>>> > however it doesnt compare that method of the .ToString() method. >>>> > >>>> > Which is best. >>>> > >>>> > Thanks >>>> > >>>> > >>>> >>>> >>>> >> >> > > "Scott M." <s-mar@nospam.nospam> schrieb: Does this really matter? The JIT compiler could inline the type conversion >> both points of view are valid, however i use the vb string methods as the >> compiler makes optimzations that can improve performance over the native >> .Net >> methods, also i find the vb methods read better. > > The VB 6.0 way are not methods, they are functions. The .NET way are > object methods. The VB.NET compiler does NOT optimize the VB 6.0 > functions to work BETTER than the natvie .NET object methods. functions. > To answer your question, ToString would be my suggestion, rather than 'ToString' and 'CStr' serve different purposes. 'ToString' won't work on > CStr(). ToString is a method of the Object Type, and since all classes > inherit from Object, all objects have this method. 'Nothing' references, which is a downside /if/ a 'Nothing' reference should be converted to an empty string. That's exactly where 'CStr' can be used. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> >> The VB 6.0 way are not methods, they are functions. The .NET way are I was merely pointing out the inacurracy of the previous post. I'll leave >> object methods. The VB.NET compiler does NOT optimize the VB 6.0 >> functions to work BETTER than the natvie .NET object methods. > > Does this really matter? The JIT compiler could inline the type > conversion functions. it up to the reader to determine if they care about the details. > As stated by others already, good programming practice would dictate that >> To answer your question, ToString would be my suggestion, rather than >> CStr(). ToString is a method of the Object Type, and since all classes >> inherit from Object, all objects have this method. > > 'ToString' and 'CStr' serve different purposes. 'ToString' won't work on > 'Nothing' references, which is a downside /if/ a 'Nothing' reference > should be converted to an empty string. That's exactly where 'CStr' can > be used. data should be validated before being converted. So, I suppose I could say, "Does it really matter since any good programmer would be checking for nothing before converting the data?". Show quoteHide quote > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/> > data should be validated before being converted. So, I suppose I could They are doing it! Except they're using CStr to do it! It "checks" for the > say, "Does it really matter since any good programmer would be checking > for nothing before converting the data?". programmer. Unless you actually need to do something ELSE based on whether a string is Nothing, it's astronomically stupid to do what you say. I mean, come on.... If s is Nothing Then Return "" Else Return s.ToString() End If Why? That's exactly what CStr does. Well, thanks for calling me stupid. If you would calm down and READ my
other posts, I have addressed why CStr() is actually more dangerous to use than ToString. Try to just understand what I'm saying for a moment...If you rely on CStr() to do your validation checks, then it will allow all Nothing values and would not be able to alert YOU the programmer to a validation error unless you add an if statement of your own that checks for "". Your example code of what I'd write is inaccurate given that if s Is Nothing, I wouldn't want and empty string in its place, I'd probably WANT an exception. If you just want to rant to hear yourself, fine - - but you seem like you are being rather close minded to the benefits of structuring your code in a more object oriented way. You also seem to believe that saving a few keystrokes of code is always better than not adding a few more important lines of code. Let me ask you something, what would you write if you didn't want to proceed with your string data when the user hasn't entered any data? I imagine the code would look very similar to what you wrote below as an example of what you'd need to write with ToString. And given that the 2 solutions are so similar, why not choose the more OO way of writing it? Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:OIBvQ6ZNGHA.2828@TK2MSFTNGP12.phx.gbl... >> data should be validated before being converted. So, I suppose I could >> say, "Does it really matter since any good programmer would be checking >> for nothing before converting the data?". > > They are doing it! Except they're using CStr to do it! It "checks" for the > programmer. Unless you actually need to do something ELSE based on whether > a string is Nothing, it's astronomically stupid to do what you say. I > mean, come on.... > > If s is Nothing Then > Return "" > Else > Return s.ToString() > End If > > Why? That's exactly what CStr does. > > -- > -C. Moya > www.cmoya.com > "Scott M." <s-mar@nospam.nospam> schrieb: Huh?! You are mixing up cases. CMM and I simply said that generally > Try to just understand what I'm saying for a moment...If you rely on > CStr() to do your validation checks, then it will allow all Nothing values > and would not be able to alert YOU the programmer to a validation error > unless you add an if statement of your own that checks for "". > > Your example code of what I'd write is inaccurate given that if s Is > Nothing, I wouldn't want and empty string in its place, I'd probably WANT > an exception. recommending not to use 'CStr' at all is plain stupid. If you /want/ an exception to be thrown, simply do not use 'CStr'! -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> Herfried,
> Huh?! You are mixing up cases. CMM and I simply said that generally Good catch,> recommending not to use 'CStr' at all is plain stupid. Cor I'm not mixing up anything. Indicating that I am stupid for recommending
not to use CStr() is what you've both said. But at the same time, you've both also admitted that CStr() can get you into trouble. So my advice is go with the code that will satisfy all scenarios and for this you both call me stupid. They are your own words Herfried, just scroll down and read them if you've forgotten. Show quoteHide quote "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:OENyTtaNGHA.2320@TK2MSFTNGP11.phx.gbl... > "Scott M." <s-mar@nospam.nospam> schrieb: >> Try to just understand what I'm saying for a moment...If you rely on >> CStr() to do your validation checks, then it will allow all Nothing >> values and would not be able to alert YOU the programmer to a validation >> error unless you add an if statement of your own that checks for "". >> >> Your example code of what I'd write is inaccurate given that if s Is >> Nothing, I wouldn't want and empty string in its place, I'd probably WANT >> an exception. > > Huh?! You are mixing up cases. CMM and I simply said that generally > recommending not to use 'CStr' at all is plain stupid. If you /want/ an > exception to be thrown, simply do not use 'CStr'! > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/> I've never admitted CStr can "get you into trouble" and I'd like you to give
one example when it might. As for "calling you stupid"... I don't think that it was anyone's intention to level a personal insult. We're simply debating the merit of your claims about CStr. Though I do think calling CStr "legacy" does sort of demonstate a bit of ignorance considering it's entirely false. > As for "calling you stupid"... I don't think that it was anyone's Then your communication skills leave much to be desired. Go back and read > intention to level a personal insult. what you've written. Well, I think at one point I confused your posts with Bob Lehmann's posts
for some reason. So, for that I apologize. The tone of your posts did not merit my pugnacious responses. (I still think you're wrong. :-) ) "Scott M." <s-mar@nospam.nospam> schrieb: There is a difference between a general recommendation and a conditional > I'm not mixing up anything. Indicating that I am stupid for recommending > not to use CStr() is what you've both said. But at the same time, you've > both also admitted that CStr() can get you into trouble. So my advice is > go with the code that will satisfy all scenarios and for this you both > call me stupid. > > They are your own words Herfried, just scroll down and read them if you've > forgotten. recommendation. Yes, I believe that recommending "never use 'CStr'" is stupid (no insult intended!) because this recommendation cannot be based on substantial arguments. It's as stupid as the recommendation "always use 'CStr'". Programming is the art of using the right tool in the right place, it's not about dogmatically using or not using certain functions. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> Carlos
> If s is Nothing Then This is in my opinion only nececarry if you declare s as Object and use > Return "" > Else > Return s.ToString() > End If > reflection or latebinding to do your job. If s is a member of an object it is forever needed to test on the existence of the object. Because that the ToString is one of the base members and not much more characthers to type do I use forever ToString, although I have to admit that it is not consistent. So seeing what you wrote in this thread we agree, with the exception of course of doing instructions to instance not needed with an not used value. :-) CorScott,
> What you write is true, however we are talking about dotNet her. In dotNet > The VB 6.0 way are not methods, they are functions. The .NET way are > object methods. The VB.NET compiler does NOT optimize the VB 6.0 > functions to work BETTER than the natvie .NET object methods. > all methods are Methods even if you call them functions. It does not matter if they are placed in the System Namespace or placed in whatever namespace including your own. In the Visual Basic namespace are many methods which are more optimized in whatever way than the standard system.Net methods. Some are just wrappers with backward compatible reasons (but absolute not all). This optimized can be to make it easier and more descripting writing a program. By instance IsDate what is nothing more than a convert in a try block, however much easier to write or by instance a Find method which is twice as fast as an IndexOf a full string. Just my opinion Cor Cor,
You are completely missing the point. My point is that writing CStr(someString) over someObject.ToString is a throwback to the VB 6.0 style of object BASED programming and not consistent with the object ORIENTED style of programming. In this context, yes there is a difference between a method and a language function. As a teacher, when I have students new to this, the question is always the same, "How do I know when you should use an object method vs. using a language function and pass it some type's value?". Type CStr() in VS.NET and it will turn blue. Blue is for language elements. Yes, internally this "function" operates as a method, but from a coding *style* perspective the developer is not using a method, they are using a language construct. For consistency sake as well as the fact that many of the old VB 6.0 "functions" don't offer any benefits over object methods, I prefer the OO way. As for CStr() in particular, I've said over and over that this is my PREFERENCE and IMHO it doesn't need to be everyone's choice. Using ToString on string values along with an Is Nothing check works in every single situation. CStr() would need an IF Then check of its own to validate its conversion, so the two approached amount to roughly the same amount of code. Now, CMM and Herfried have changed their original stance and admitted that if you need to process Nothing differently than a string, you will have problems with CStr(). And in *my* travels, handling Nothing differently than a string value is pretty darn common, which means using ToString makes perfect sense in every situation I encounter. For advocating this, CMM and Herfried have decided to get personal and call me stupid. I don't know CMM, but I wouldn't have expected that from Herfried. -Scott Show quoteHide quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:%23qxx%233fNGHA.3732@TK2MSFTNGP10.phx.gbl... > Scott, > >> >> The VB 6.0 way are not methods, they are functions. The .NET way are >> object methods. The VB.NET compiler does NOT optimize the VB 6.0 >> functions to work BETTER than the natvie .NET object methods. >> > What you write is true, however we are talking about dotNet her. In dotNet > all methods are Methods even if you call them functions. It does not > matter if they are placed in the System Namespace or placed in whatever > namespace including your own. > > In the Visual Basic namespace are many methods which are more optimized in > whatever way than the standard system.Net methods. Some are just wrappers > with backward compatible reasons (but absolute not all). > > This optimized can be to make it easier and more descripting writing a > program. > By instance IsDate what is nothing more than a convert in a try block, > however much easier to write or by instance a Find method which is twice > as fast as an IndexOf a full string. > > Just my opinion > > Cor > > "Scott M." <s-mar@nospam.nospam> wrote in message I hope you're teaching your students about encapsulation. Because that's news:%231LqNCiNGHA.668@TK2MSFTNGP11.phx.gbl... > Cor, > > You are completely missing the point. My point is that writing > CStr(someString) over someObject.ToString is a throwback to the VB 6.0 > style of object BASED programming and not consistent with the object > ORIENTED style of programming. exactly what CStr is. Also, the fact that by-design the .NET String object violates the strict "object ORIENTED" notion that you seem to be harping on. For instance, s.ToUpper() doesn't exactly perform a true OO operation (in that s isn't modified). So there goes that. > In this context, yes there is a difference between a method and a language Also known as a keyword, right? Well, that's what makes VB "VB." > function. As a teacher, when I have students new to this, the question is > always the same, "How do I know when you should use an object method vs. > using a language function and pass it some type's value?". Type CStr() in > VS.NET and it will turn blue. Blue is for language elements. Yes, > internally this "function" operates as a method, but from a coding *style* > perspective the developer is not using a method, they are using a language > construct. Respectfully, if you don't like the things that make VB "VB," maybe you shouldn't be using or teaching VB. C# seems much better suited to your preferences, no? > For consistency sake as well as the fact that many of the old VB 6.0 They offer many benefits. Maybe it might help if somebody wrapped that all > "functions" don't offer any benefits over object methods, I prefer the OO > way. up as Shared Methods in a "StringUtility" class? Does StringUtility.CStr(...) make it easier for you to use? Would that make it more "OO" to you? > As for CStr() in particular, I've said over and over that this is my The latter accomplishes encapsulation. The former (your method) accomplishes > PREFERENCE and IMHO it doesn't need to be everyone's choice. Using > ToString on string values along with an Is Nothing check works in every > single situation. CStr() would need an IF Then check of its own to > validate its conversion, so the two approached amount to roughly the same > amount of code. needlessly verbose code. > Now, CMM and Herfried have changed their original stance and admitted that I admitted nothing that isn't already obvious nor changed my stance. If you > if you need to process Nothing differently than a string, you will have > problems with CStr(). need to treat Nothing differently than EmptyString then it's obvious you wouldn't use CStr. Instead, it would behoove you to write your own helper function.... like, SafeGetString(object, valueIfNothing) As String... instead of littering If Is Nothing conditionals all over your code. Again encapsulation is a good practice. > And in *my* travels, handling Nothing differently than a string value is In *my* travels, you usually want to treat Nothing as EmptyString. The > pretty darn common, which means using ToString makes perfect sense in > every situation I encounter. instance where this isn't true is rare and specialized. Indeed, the VB language stresses this in that its Equality operators reinforce this notion. I've alluded to this in another post in this thread... but, possibly VB is not the language for you. > For advocating this, CMM and Herfried have decided to get personal and No one called you stupid... as a personal attack. If anything I said > call me stupid. I don't know CMM, but I wouldn't have expected that from > Herfried. offended you, I apologize. > I hope you're teaching your students about encapsulation. Because that's I am and I do. But CStr() is not an object method as such. It is a > exactly what CStr is. language element that (as this thread has shown) confuses many who encounter it. My OPINION and PREFERENCE is to avoid it. I could easily turn your statements around to say that to not use ToString is being ignorant of the underlying framework that VB runs on. > Also, the fact that by-design the .NET String object violates the strict The immutable nature of the String class does not break any OO doctrine. It > "object ORIENTED" notion that you seem to be harping on. For instance, > s.ToUpper() doesn't exactly perform a true OO operation (in that s isn't > modified). So there goes that. simply has to do with memory management. There goes nothing. > In this context, yes there is a difference between a method and a language That's your opinion and you are entitled to it. There are many things that >> function. As a teacher, when I have students new to this, the question >> is always the same, "How do I know when you should use an object method >> vs. using a language function and pass it some type's value?". Type >> CStr() in VS.NET and it will turn blue. Blue is for language elements. >> Yes, internally this "function" operates as a method, but from a coding >> *style* perspective the developer is not using a method, they are using a >> language construct. > > Also known as a keyword, right? Well, that's what makes VB "VB." > Respectfully, if you don't like the things that make VB "VB," maybe you > shouldn't be using or teaching VB. C# seems much better suited to your > preferences, no? are part of VB.NET because MS hasn't found an appropriate way of losing it from the language. I call CStr(), LCase(), UCase(), Time(), Hour(), Replace(), Split() et all legacy functions because I believe that's what they are. I believe they exist as part of the VB language syntax to provide VB 6.0 developers (and the millions of lines of code written by them) a transition into the .NET programming platform. I do firmly believe that, over time, they will be phased out of the language and so I steer clear of them. > Yes.>> For consistency sake as well as the fact that many of the old VB 6.0 >> "functions" don't offer any benefits over object methods, I prefer the OO >> way. > > They offer many benefits. Maybe it might help if somebody wrapped that all > up as Shared Methods in a "StringUtility" class? Does > StringUtility.CStr(...) make it easier for you to use? Would that make it > more "OO" to you? > Your opinion. There are those that say that the entire VB language is >> As for CStr() in particular, I've said over and over that this is my >> PREFERENCE and IMHO it doesn't need to be everyone's choice. Using >> ToString on string values along with an Is Nothing check works in every >> single situation. CStr() would need an IF Then check of its own to >> validate its conversion, so the two approached amount to roughly the same >> amount of code. > > The latter accomplishes encapsulation. The former (your method) > accomplishes needlessly verbose code. verbose. If you don't like verboseness, may I respectfully suggest you try C# and that maybe VB.NET isn't for you? Scott,
> You can find that, which is your own right. However it is not an official > That's your opinion and you are entitled to it. There are many things > that are part of VB.NET because MS hasn't found an appropriate way of > losing it from the language. I call CStr(), LCase(), UCase(), Time(), > Hour(), Replace(), Split() et all legacy functions because I believe > that's what they are. I believe they exist as part of the VB language > syntax to provide VB 6.0 developers (and the millions of lines of code > written by them) a transition into the .NET programming platform. I do > firmly believe that, over time, they will be phased out of the language > and so I steer clear of them. > Microsoft statement. Those methods you mention are from Visual Basic not VB6. For upgrading from VB6 is the Microsoft VisualBasic Compatible Namespace. However that is completely something different. The methods you name above are not in that. That the Visual Basic methods are not in the standard namespace is for me obvious. In past you would never had a Java or C++ programmer who would look to a program language that had statements like Visual Basic. So they are probably therefore kept hidden in C#. (This last is just my own idea, I think that this will ever be committed). There is no problem to use the by you so avoided methods in C# or C++ managed. However to be clear, there is no reason that you "should" use them, although a student who does not know them, does not know Visual Basic Net. Cor I am aware of the VB Compatability Namespace and the fact that these
*functions* are not defined in them. Still and all, I personally believe they will one day be deprecated and my students are taught this way because the MS consultant hired by the global insurance company that I train for has indicated his feelings about the future of these *functions* to the company and myself. As a result, the companies that I do .NET training for have instituted policies that state that these types of functions should not be used. Show quoteHide quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:eYNCQejNGHA.3924@TK2MSFTNGP14.phx.gbl... > Scott, > >> >> That's your opinion and you are entitled to it. There are many things >> that are part of VB.NET because MS hasn't found an appropriate way of >> losing it from the language. I call CStr(), LCase(), UCase(), Time(), >> Hour(), Replace(), Split() et all legacy functions because I believe >> that's what they are. I believe they exist as part of the VB language >> syntax to provide VB 6.0 developers (and the millions of lines of code >> written by them) a transition into the .NET programming platform. I do >> firmly believe that, over time, they will be phased out of the language >> and so I steer clear of them. >> > > You can find that, which is your own right. However it is not an official > Microsoft statement. > > Those methods you mention are from Visual Basic not VB6. > > For upgrading from VB6 is the Microsoft VisualBasic Compatible Namespace. > However that is completely something different. The methods you name above > are not in that. > > That the Visual Basic methods are not in the standard namespace is for me > obvious. In past you would never had a Java or C++ programmer who would > look to a program language that had statements like Visual Basic. So they > are probably therefore kept hidden in C#. (This last is just my own idea, > I think that this will ever be committed). > > There is no problem to use the by you so avoided methods in C# or C++ > managed. > > However to be clear, there is no reason that you "should" use them, > although a student who does not know them, does not know Visual Basic Net. > > Cor > > > > If anything, these functions might be rolled into the Framework as these
"legacy" functions provide GREATER functionality than what is currently in the framework. The Substring vs Left/Right/Mid example I give in another post is a great example of this. But Cor's statement, "However to be clear, there is no reason that you "should" use them, although a student who does not know them, does not know Visual Basic Net," is by far the most lucid and definitive statement on this whole topic. "Scott M." <s-mar@nospam.nospam> wrote in message As you stated stated, you think StringUtility.CStr() would better conform tonews:uHBj3HjNGHA.984@tk2msftngp13.phx.gbl... >> I hope you're teaching your students about encapsulation. Because that's >> exactly what CStr is. > > I am and I do. But CStr() is not an object method as such. It is a > language element that (as this thread has shown) confuses many who > encounter it. My OPINION and PREFERENCE is to avoid it. I could easily > turn your statements around to say that to not use ToString is being > ignorant of the underlying framework that VB runs on. your preferences. Perhaps teaching your students how keywords like CStr compile inline or the existence of other functions in Microsoft.VisualBasic and the notion of scope and how the Imports statement works and what it's supposed to accomplish. CStr is simply a utility method (compile time conversion?) that sets VB apart. The "Framework" can't be all things to all languages.... as I expand upon below.... >> Also, the fact that by-design the .NET String object violates the strict And CStr simply has to do with encapsulation. If s.ToUpper doesn't break OO>> "object ORIENTED" notion that you seem to be harping on. For instance, >> s.ToUpper() doesn't exactly perform a true OO operation (in that s isn't >> modified). So there goes that. > > The immutable nature of the String class does not break any OO doctrine. > It simply has to do with memory management. There goes nothing. doctrine in your book, then I don't seee how Microsoft.VisualBasic.CStr() does. Show quoteHide quote >> In this context, yes there is a difference between a method and a You base this opinion on what?>> language >>> function. As a teacher, when I have students new to this, the question >>> is always the same, "How do I know when you should use an object method >>> vs. using a language function and pass it some type's value?". Type >>> CStr() in VS.NET and it will turn blue. Blue is for language elements. >>> Yes, internally this "function" operates as a method, but from a coding >>> *style* perspective the developer is not using a method, they are using >>> a language construct. >> >> Also known as a keyword, right? Well, that's what makes VB "VB." >> Respectfully, if you don't like the things that make VB "VB," maybe you >> shouldn't be using or teaching VB. C# seems much better suited to your >> preferences, no? > > That's your opinion and you are entitled to it. There are many things > that are part of VB.NET because MS hasn't found an appropriate way of > losing it from the language. > I call CStr(), LCase(), UCase(), Time(), Hour(), Replace(), Split() et all You "Believe" based on what? Here's why you're wrong: Using> legacy functions because I believe that's what they are. String.Substring(10) on a string that's only 5 characters long will yield an exception. Left(s, 10) does not. Sure you can add conditional length checking code.... but that's why VB's encapsulation methods set it apart..... If Not s Is Nothing Then If s.Length >= 10 Then s2 = s.Substring(10) End If End If = s2 = Left(s , 10) Come on. Isn't this obvious? Do you actually prefer the former? If you do, there is NO POINT in using VB. Use C#. > I believe they exist as part of the VB language syntax to provide VB 6.0 C# has a "string" ALIAS for System.String (note the All lowercase). There> developers (and the millions of lines of code written by them) a > transition into the .NET programming platform. I do firmly believe that, > over time, they will be phased out of the language and so I steer clear of > them. weren't "millions of lines" of C# code out there when C# came out so why did Microsoft provide that alias as part of the language? No, these things that you say are "legacy" are there because they are what make VB a BASIC-derived language. The .NET platform is not the end all and be all. It is simply a foundation upon which certain languages will provide certain features *in addition* to the building blocks already in the framework platform. If you get tunnel vision and zero in on the framework SOLELY, you're missing out. >>> For consistency sake as well as the fact that many of the old VB 6.0 Then>>> "functions" don't offer any benefits over object methods, I prefer the >>> OO way. >> >> They offer many benefits. Maybe it might help if somebody wrapped that >> all up as Shared Methods in a "StringUtility" class? Does >> StringUtility.CStr(...) make it easier for you to use? Would that make it >> more "OO" to you? > > Yes. 1) encapsulate CStr in your own StringUtility 2) write your own implementation of CStr if you think you can do a BETTER job than Microsoft. But, for heaven's sake don't litter your code with zillions of needless conditionals. Again, encapsulation is key. >>> As for CStr() in particular, I've said over and over that this is my You're mixing things up again. VB may be a verbose language in that it uses>>> PREFERENCE and IMHO it doesn't need to be everyone's choice. Using >>> ToString on string values along with an Is Nothing check works in every >>> single situation. CStr() would need an IF Then check of its own to >>> validate its conversion, so the two approached amount to roughly the >>> same amount of code. >> >> The latter accomplishes encapsulation. The former (your method) >> accomplishes needlessly verbose code. > > Your opinion. There are those that say that the entire VB language is > verbose. If you don't like verboseness, may I respectfully suggest you > try C# and that maybe VB.NET isn't for you? longer english-like keywords. It is NOT a verbose language in that the 5 lines of code that are necessary in a C# program are handled by one line or NO code at all in VB.... such as declaritive event handling using the Handles clause which C# lacks.... or my Substring() example above! "Scott M." <s-mar@nospam.nospam> schrieb: Programming is about religious fundamentalism and feature-evangelism. I >> I hope you're teaching your students about encapsulation. Because that's >> exactly what CStr is. > > I am and I do. But CStr() is not an object method as such. It is a > language element that (as this thread has shown) confuses many who > encounter it. My OPINION and PREFERENCE is to avoid it. I could easily > turn your statements around to say that to not use ToString is being > ignorant of the underlying framework that VB runs on. prefer to use a toolbox which contains multiple tools which I can choose the ideal tool for a certain situation from instead of a toolbox which only contains a hammer. OO is a hammer, but not a complete toolbox. The biggest problem I experience with developers nowadays is that they think that a single paradigm can be used to write ideal solutions in every case. I believe that this is totally wrong. The VB.NET programming language is a perfect example of a language which tightly integrates different programming paradigms (procedural programming, OOP, declarative programming, functional programming, and relational programming (XLINQ, LINQ)) in a single programming language. VB.NET is a well-filled toolbox. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> Scott,
> internally this "function" operates as a method, but from a coding *style* With that you want to say that this in C# should not be used to cast> perspective the developer is not using a method, they are using a language > construct. DataTable MyTable = ((DataSet) DataGrid.DataSource).Tables[0]; I don't know another method by the way in C#. As I have often said is for me a language grown up when it has synoniems to express the same things. Otherwise it is not a language but a code system. However, as you probably know, just an often by me told thought, Herfried and Carlos did not tell that you are stupid. They found the construction you made stupid, what tells nothing about you. That we do we all I hope sometimes (at least me). Cor Scott,
What is this for you? \\\ Imports ScottS.Cmm Class WhatEver Private Sub WhatEver() Dim i As Integer = 1 Dim a As String = CIS(i) End Sub End Class /// In a different DLL \\\ Public Class Cmm Public Shared Function CIS(ByVal i As Integer) As String Return i.ToString End Function End Class /// Cor It prefer CStr as it's compiled as an inline conversion. That's beautiful.
;-) But, your observation about "Imports" is on point... and I think the whole notion is eluding Scott. I don't understand the whole CStr not being OO idea at all. "CMM" <cmm@nospam.com> schrieb: ACK.> It prefer CStr as it's compiled as an inline conversion. That's beautiful. > ;-) > But, your observation about "Imports" is on point... and I think the whole ACK. As 'CStr' is a conversion operator it's basically as object-oriented > notion is eluding Scott. I don't understand the whole CStr not being OO > idea at all. as operators and operator overloading in general. Object-orientiation doesn't imply using the dot notation. It's about creating entities which have attributes and can perform operations. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> Exactly! It's not any less OO than
= (string) object In the C#, C/C++, and Java world. It just so happens that in the B.A.S.I.C. world, our casting operators are a little smarter in implementation and a little wordier in their invokation. Which is why we have CStr().... 1) it's the same exact thing as CType(Object, String) AFAIK, and 2) it's pretier and easier to read.... just like the rest of the language. This whole "if it's not a feature of the Framework proper it's not good" idea is bizarre. P.S. I have always liked the elegance of C's casting though. :-) "CMM" <cmm@nospam.com> schrieb: I liked the 'C*' casting more than the '(<type>)<...>' casting because it > P.S. I have always liked the elegance of C's casting though. :-) doesn't suffer from the "lots of braces" problem ('CType(x.U, Z).Y' vs. '((Z)x.U).Y'). -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> Your question boils down to this one: What object is CStr() a method of?
Show quoteHide quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:eZI8WljNGHA.2560@TK2MSFTNGP09.phx.gbl... > Scott, > > What is this for you? > > \\\ > Imports ScottS.Cmm > Class WhatEver > Private Sub WhatEver() > Dim i As Integer = 1 > Dim a As String = CIS(i) > End Sub > End Class > /// > In a different DLL > \\\ > Public Class Cmm > Public Shared Function CIS(ByVal i As Integer) As String > Return i.ToString > End Function > End Class > /// > > Cor > > CStr is compiled as an inline conversion.... similarly to C#'s AND C++'s
(and probably Java's) s2 = (string) object gasp! that's not OO!!!! On the other hand, Left/Right/Mid/etc etc are function in Microsoft.VisualBasic. So maybe it might help to teach your students what Imports means or have them always type out Microsoft.VisualBasic.Left or Microsoft.VisualBasic.MsgBox etc etc. Show quoteHide quote "Scott M." <s-mar@nospam.nospam> wrote in message news:eQy785jNGHA.1132@TK2MSFTNGP10.phx.gbl... > Your question boils down to this one: What object is CStr() a method of? > > > > "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message > news:eZI8WljNGHA.2560@TK2MSFTNGP09.phx.gbl... >> Scott, >> >> What is this for you? >> >> \\\ >> Imports ScottS.Cmm >> Class WhatEver >> Private Sub WhatEver() >> Dim i As Integer = 1 >> Dim a As String = CIS(i) >> End Sub >> End Class >> /// >> In a different DLL >> \\\ >> Public Class Cmm >> Public Shared Function CIS(ByVal i As Integer) As String >> Return i.ToString >> End Function >> End Class >> /// >> >> Cor >> >> > > Please don't drag in unrelated issues into this conversation. I fully
understand what Imports and Namespaces are and my students learn them. Your point that these are language elements declared in the Microsoft.VisualBasic don't change any of what I've been saying about my preference not to use CStr(). Did you really think I'd fall into the camp that wants to use Left/Right and MsgBox instead of the MessageBox class and the other String object methods anyway? My question still stands... What object is CStr() a method of? Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:uk4Yb9jNGHA.2624@TK2MSFTNGP12.phx.gbl... > CStr is compiled as an inline conversion.... similarly to C#'s AND C++'s > (and probably Java's) > s2 = (string) object > gasp! that's not OO!!!! > > On the other hand, Left/Right/Mid/etc etc are function in > Microsoft.VisualBasic. So maybe it might help to teach your students what > Imports means or have them always type out Microsoft.VisualBasic.Left or > Microsoft.VisualBasic.MsgBox etc etc. > > -- > -C. Moya > www.cmoya.com > "Scott M." <s-mar@nospam.nospam> wrote in message > news:eQy785jNGHA.1132@TK2MSFTNGP10.phx.gbl... >> Your question boils down to this one: What object is CStr() a method of? >> >> >> >> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message >> news:eZI8WljNGHA.2560@TK2MSFTNGP09.phx.gbl... >>> Scott, >>> >>> What is this for you? >>> >>> \\\ >>> Imports ScottS.Cmm >>> Class WhatEver >>> Private Sub WhatEver() >>> Dim i As Integer = 1 >>> Dim a As String = CIS(i) >>> End Sub >>> End Class >>> /// >>> In a different DLL >>> \\\ >>> Public Class Cmm >>> Public Shared Function CIS(ByVal i As Integer) As String >>> Return i.ToString >>> End Function >>> End Class >>> /// >>> >>> Cor >>> >>> >> >> > > > My question still stands... What object is CStr() a method of? And as I already answered it's an operator that compiles as an inline conversion or "cast" if you will.... just like "str = (string) object" in the C-derived world, which is also not (what you call) an "object" method. It just so happens that VB's casting operators are more full-featured than simple casts. The *other* (what you call) deprecated functions are shared methods in the Microsoft.VisualBasic "object." Show quoteHide quote "Scott M." <s-mar@nospam.nospam> wrote in message news:e$DB7VkNGHA.3276@TK2MSFTNGP09.phx.gbl... > Please don't drag in unrelated issues into this conversation. I fully > understand what Imports and Namespaces are and my students learn them. > Your point that these are language elements declared in the > Microsoft.VisualBasic don't change any of what I've been saying about my > preference not to use CStr(). Did you really think I'd fall into the camp > that wants to use Left/Right and MsgBox instead of the MessageBox class > and the other String object methods anyway? > > My question still stands... What object is CStr() a method of? > > > > "CMM" <cmm@nospam.com> wrote in message > news:uk4Yb9jNGHA.2624@TK2MSFTNGP12.phx.gbl... >> CStr is compiled as an inline conversion.... similarly to C#'s AND C++'s >> (and probably Java's) >> s2 = (string) object >> gasp! that's not OO!!!! >> >> On the other hand, Left/Right/Mid/etc etc are function in >> Microsoft.VisualBasic. So maybe it might help to teach your students what >> Imports means or have them always type out Microsoft.VisualBasic.Left or >> Microsoft.VisualBasic.MsgBox etc etc. >> >> -- >> -C. Moya >> www.cmoya.com >> "Scott M." <s-mar@nospam.nospam> wrote in message >> news:eQy785jNGHA.1132@TK2MSFTNGP10.phx.gbl... >>> Your question boils down to this one: What object is CStr() a method >>> of? >>> >>> >>> >>> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message >>> news:eZI8WljNGHA.2560@TK2MSFTNGP09.phx.gbl... >>>> Scott, >>>> >>>> What is this for you? >>>> >>>> \\\ >>>> Imports ScottS.Cmm >>>> Class WhatEver >>>> Private Sub WhatEver() >>>> Dim i As Integer = 1 >>>> Dim a As String = CIS(i) >>>> End Sub >>>> End Class >>>> /// >>>> In a different DLL >>>> \\\ >>>> Public Class Cmm >>>> Public Shared Function CIS(ByVal i As Integer) As String >>>> Return i.ToString >>>> End Function >>>> End Class >>>> /// >>>> >>>> Cor >>>> >>>> >>> >>> >> >> > > So now you have two things to teach (or not).
1) What inline conversion / casting operators are... and why you think they're not OO (make sure to look at how other languages do it in just as non-OO ways). 2) Why methods in Microsoft.VisualBasic are somehow not OO. Confuse them even more by telling them that C# folks can easily use these "non-OO" methods by importing the Microsoft.VisualBasic namespace! Wait, how is that possible? Then, backpeddle and explain YOUR special notion of OO and how it differs from the real world. Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:ePw2C9mNGHA.2644@TK2MSFTNGP10.phx.gbl... >> My question still stands... What object is CStr() a method of? > > And as I already answered it's an operator that compiles as an inline > conversion or "cast" if you will.... just like "str = (string) object" in > the C-derived world, which is also not (what you call) an "object" method. > It just so happens that VB's casting operators are more full-featured than > simple casts. > > The *other* (what you call) deprecated functions are shared methods in the > Microsoft.VisualBasic "object." > > > -- > -C. Moya > www.cmoya.com > "Scott M." <s-mar@nospam.nospam> wrote in message > news:e$DB7VkNGHA.3276@TK2MSFTNGP09.phx.gbl... >> Please don't drag in unrelated issues into this conversation. I fully >> understand what Imports and Namespaces are and my students learn them. >> Your point that these are language elements declared in the >> Microsoft.VisualBasic don't change any of what I've been saying about my >> preference not to use CStr(). Did you really think I'd fall into the >> camp that wants to use Left/Right and MsgBox instead of the MessageBox >> class and the other String object methods anyway? >> >> My question still stands... What object is CStr() a method of? >> >> >> >> "CMM" <cmm@nospam.com> wrote in message >> news:uk4Yb9jNGHA.2624@TK2MSFTNGP12.phx.gbl... >>> CStr is compiled as an inline conversion.... similarly to C#'s AND C++'s >>> (and probably Java's) >>> s2 = (string) object >>> gasp! that's not OO!!!! >>> >>> On the other hand, Left/Right/Mid/etc etc are function in >>> Microsoft.VisualBasic. So maybe it might help to teach your students >>> what Imports means or have them always type out >>> Microsoft.VisualBasic.Left or Microsoft.VisualBasic.MsgBox etc etc. >>> >>> -- >>> -C. Moya >>> www.cmoya.com >>> "Scott M." <s-mar@nospam.nospam> wrote in message >>> news:eQy785jNGHA.1132@TK2MSFTNGP10.phx.gbl... >>>> Your question boils down to this one: What object is CStr() a method >>>> of? >>>> >>>> >>>> >>>> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message >>>> news:eZI8WljNGHA.2560@TK2MSFTNGP09.phx.gbl... >>>>> Scott, >>>>> >>>>> What is this for you? >>>>> >>>>> \\\ >>>>> Imports ScottS.Cmm >>>>> Class WhatEver >>>>> Private Sub WhatEver() >>>>> Dim i As Integer = 1 >>>>> Dim a As String = CIS(i) >>>>> End Sub >>>>> End Class >>>>> /// >>>>> In a different DLL >>>>> \\\ >>>>> Public Class Cmm >>>>> Public Shared Function CIS(ByVal i As Integer) As String >>>>> Return i.ToString >>>>> End Function >>>>> End Class >>>>> /// >>>>> >>>>> Cor >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > I just reread this last post. I'm intrigued. I don't mean to be offensive
but I think your notions are severely misplaced. Are you really a teacher? If you're teaching System.Windows.Forms.MessageBox() rather than MsgBox() you are really not teaching VB.... and you've really missed the whole point. You apparently think that everything in the Microsoft.VisualBasic namespace is "deprecated." Apparently if it's not in the Framework it's somehow bad. Where do you get this idea? I think it shows a really deep misconception at the heart of your notions. Frankly, I'm a bit aghast. I've already explained why I teach MessageBox.show and not MsgBox(). Also,
(to remind you of what I've already said), I teach for private corporations who have had their best practices shaped by MS input. How I would teach "VB.NET" to the general public is not the same thing. Please try to stay on topic. I have been and continue to discuss my preference for ToString, rather than CStr(). Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:ujGjqPnNGHA.2624@TK2MSFTNGP12.phx.gbl... >I just reread this last post. I'm intrigued. I don't mean to be offensive >but I think your notions are severely misplaced. Are you really a teacher? > > If you're teaching System.Windows.Forms.MessageBox() rather than MsgBox() > you are really not teaching VB.... and you've really missed the whole > point. You apparently think that everything in the Microsoft.VisualBasic > namespace is "deprecated." Apparently if it's not in the Framework it's > somehow bad. Where do you get this idea? I think it shows a really deep > misconception at the heart of your notions. Frankly, I'm a bit aghast. > > -- > -C. Moya > www.cmoya.com > You say "Stay On topic?" How am I not on topic? This was your first original
post: "you should view *all* of the old "data-type" specific functions as legacy functions" [emphasis added] Then you claim CType or ToString should replace CStr. Then you say, "*All* date/time functions would be replaced with methods and properties of the Date class. All string functions would be replaced with methods and properties of the String class." [emphasis added]. That was your original post. I AM on topic. Show quoteHide quote "Scott M." <s-mar@nospam.nospam> wrote in message news:eTWTJBpNGHA.1676@TK2MSFTNGP09.phx.gbl... > I've already explained why I teach MessageBox.show and not MsgBox(). > Also, (to remind you of what I've already said), I teach for private > corporations who have had their best practices shaped by MS input. How I > would teach "VB.NET" to the general public is not the same thing. Please > try to stay on topic. I have been and continue to discuss my preference > for ToString, rather than CStr(). > > > "CMM" <cmm@nospam.com> wrote in message > news:ujGjqPnNGHA.2624@TK2MSFTNGP12.phx.gbl... >>I just reread this last post. I'm intrigued. I don't mean to be offensive >>but I think your notions are severely misplaced. Are you really a teacher? >> >> If you're teaching System.Windows.Forms.MessageBox() rather than MsgBox() >> you are really not teaching VB.... and you've really missed the whole >> point. You apparently think that everything in the Microsoft.VisualBasic >> namespace is "deprecated." Apparently if it's not in the Framework it's >> somehow bad. Where do you get this idea? I think it shows a really deep >> misconception at the heart of your notions. Frankly, I'm a bit aghast. >> >> -- >> -C. Moya >> www.cmoya.com >> > > Scott,
| My question still stands... What object is CStr() a method of? Ultimately: Its a method of the object that you pass as a parameter.As has been pointed out CStr is shorthand for CType(value, String). In VS 2005 you can overload CType for individual types. Which means you could define a conversion from a type to String, such as: Public Class Something Public Shared Narrowing Operator CType(ByVal value As Something) As String Return value.ToString() End Operator End Class Then you could use CStr to convert from that type to a String. Public Sub Main(ByVal args As String()) Dim aSomething As New Something Dim aString As String = CType(aSomething, String) ' alternatively aString = CStr(aSomething) End Sub In my example I have defined conversions from Something to String to simply be Something.ToString, however! that is *NOT* a requirement. Conversion to a string may in fact be a different operation then the ToString method! (although I would carefully evaluate types where ToString & CStr are defined differently). More importantly ToString can be defined on a type where CStr is not. For example ToString may return a human readable format for use in List Boxes, where as CStr may return a string of hex digits... Generally I would only define CStr (as above) where it is common to convert to & from the type & a String. In which case I would also define: Public Shared Narrowing Operator CType(ByVal value As String) As Something Public Shared Function FromString(ByVal value As String) As Something -- Show quoteHide quoteHope this helps Jay [MVP - Outlook] ..NET Application Architect, Enthusiast, & Evangelist T.S. Bradley - http://www.tsbradley.net "Scott M." <s-mar@nospam.nospam> wrote in message news:e$DB7VkNGHA.3276@TK2MSFTNGP09.phx.gbl... | Please don't drag in unrelated issues into this conversation. I fully | understand what Imports and Namespaces are and my students learn them. Your | point that these are language elements declared in the Microsoft.VisualBasic | don't change any of what I've been saying about my preference not to use | CStr(). Did you really think I'd fall into the camp that wants to use | Left/Right and MsgBox instead of the MessageBox class and the other String | object methods anyway? | | My question still stands... What object is CStr() a method of? | | | | "CMM" <cmm@nospam.com> wrote in message | news:uk4Yb9jNGHA.2624@TK2MSFTNGP12.phx.gbl... | > CStr is compiled as an inline conversion.... similarly to C#'s AND C++'s | > (and probably Java's) | > s2 = (string) object | > gasp! that's not OO!!!! | > | > On the other hand, Left/Right/Mid/etc etc are function in | > Microsoft.VisualBasic. So maybe it might help to teach your students what | > Imports means or have them always type out Microsoft.VisualBasic.Left or | > Microsoft.VisualBasic.MsgBox etc etc. | > | > -- | > -C. Moya | > www.cmoya.com | > "Scott M." <s-mar@nospam.nospam> wrote in message | > news:eQy785jNGHA.1132@TK2MSFTNGP10.phx.gbl... | >> Your question boils down to this one: What object is CStr() a method of? | >> | >> | >> | >> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message | >> news:eZI8WljNGHA.2560@TK2MSFTNGP09.phx.gbl... | >>> Scott, | >>> | >>> What is this for you? | >>> | >>> \\\ | >>> Imports ScottS.Cmm | >>> Class WhatEver | >>> Private Sub WhatEver() | >>> Dim i As Integer = 1 | >>> Dim a As String = CIS(i) | >>> End Sub | >>> End Class | >>> /// | >>> In a different DLL | >>> \\\ | >>> Public Class Cmm | >>> Public Shared Function CIS(ByVal i As Integer) As String | >>> Return i.ToString | >>> End Function | >>> End Class | >>> /// | >>> | >>> Cor | >>> | >>> | >> | >> | > | > | | > By instance IsDate what is nothing more than a convert in a try block, Cor, > however much easier to write This was the case in the 1.x implementation. However, in 2.0, IsDate wraps TryParse and avoids the exceptions. (from the IL: L_001c: call bool Microsoft.VisualBasic.CompilerServices.Conversions::TryParseDate(string, [mscorlib]System.DateTime&) In this case, TryParse is faster as IsDate just throws away the result of the cast. If you directly use TryParse and continue working with the result, your performance improves. (see http://devauthority.com/blogs/jwooley/archive/2006/02/15/747.aspx) Jim Wooley I don't think that's true at all. First off, CStr,CBool, Etc. are all just
easier-to-read specialized wrappers around CType..... which in and of itself is a special "VB" construct. The true "non-VB" casting operator is DirectCast(...). Contrary to what Scott M says you're SUPPOSED to use them. What's the point of using VB if you're not going to use its special methods that make your life easier? This is straight from the VB documentation: "As a rule, you should use the Visual Basic type conversion functions in preference to the .NET Framework methods such as ToString(), either on the Convert class or on an individual type structure or class. The Visual Basic functions are designed for optimal interaction with Visual Basic code, and they also make your source code shorter and easier to read. In addition, the ..NET Framework conversion methods do not always produce the same results as the Visual Basic functions, for example when converting Boolean to Integer. For more information, see Troubleshooting Data Types." In addition, although I'm a guy who always initializes strings and objects as soon as possible rather than have them sit around until my algorithm uses them- so I don't really care about the following- but, there's an advantage to using VB's functions: they interpret "Nothing." You can't use the OO methods on a string that is "Nothing" (s.ToUpper for instance won't work). Show quoteHide quote "Scott M." <s-mar@nospam.nospam> wrote in message news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... > IMHO (and this has been debated for quite some time now), you should view > all of the old "data-type" specific functions as legacy functions and no > longer use them. Instead, use the more object-oriented methods of a type. > > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or > .ToString > All date/time functions would be replaced with methods and properties of > the Date class > All string functions would be replaced with methods and properties of the > String class. > > et all. > > > "Sean" <S***@discussions.microsoft.com> wrote in message > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... >> Book I am reading says that Cstr() is best method for efficency and >> safety >> however it doesnt compare that method of the .ToString() method. >> >> Which is best. >> >> Thanks >> >> > > >> You can't use the OO methods on a string that is "Nothing" Why would you want to?Oh, I get it, you're too lazy to check the data before performing an operation it. Isn't checking your data a 100 level concept? I'm guessing that On Error Resume Next is one of your friends too. Bob Lehmann Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:%23h%23gzeNNGHA.1676@TK2MSFTNGP09.phx.gbl... > I don't think that's true at all. First off, CStr,CBool, Etc. are all just > easier-to-read specialized wrappers around CType..... which in and of itself > is a special "VB" construct. The true "non-VB" casting operator is > DirectCast(...). > > Contrary to what Scott M says you're SUPPOSED to use them. What's the point > of using VB if you're not going to use its special methods that make your > life easier? This is straight from the VB documentation: > > "As a rule, you should use the Visual Basic type conversion functions in > preference to the .NET Framework methods such as ToString(), either on the > Convert class or on an individual type structure or class. The Visual Basic > functions are designed for optimal interaction with Visual Basic code, and > they also make your source code shorter and easier to read. In addition, the > .NET Framework conversion methods do not always produce the same results as > the Visual Basic functions, for example when converting Boolean to Integer. > For more information, see Troubleshooting Data Types." > > In addition, although I'm a guy who always initializes strings and objects > as soon as possible rather than have them sit around until my algorithm uses > them- so I don't really care about the following- but, there's an advantage > to using VB's functions: they interpret "Nothing." You can't use the OO > methods on a string that is "Nothing" (s.ToUpper for instance won't work). > > -- > -C. Moya > www.cmoya.com > "Scott M." <s-mar@nospam.nospam> wrote in message > news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... > > IMHO (and this has been debated for quite some time now), you should view > > all of the old "data-type" specific functions as legacy functions and no > > longer use them. Instead, use the more object-oriented methods of a type. > > > > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or > > .ToString > > All date/time functions would be replaced with methods and properties of > > the Date class > > All string functions would be replaced with methods and properties of the > > String class. > > > > et all. > > > > > > "Sean" <S***@discussions.microsoft.com> wrote in message > > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... > >> Book I am reading says that Cstr() is best method for efficency and > >> safety > >> however it doesnt compare that method of the .ToString() method. > >> > >> Which is best. > >> > >> Thanks > >> > >> > > > > > > Wow, what happened to put you in this mood?
Checking if a variable actually contains data before doing a convert to upper case is simply too much code. If you can avoid that it makes the code a lot better readable. Show quoteHide quote "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message news:epp0n5NNGHA.3856@TK2MSFTNGP12.phx.gbl... >>> You can't use the OO methods on a string that is "Nothing" > > Why would you want to? > > Oh, I get it, you're too lazy to check the data before performing an > operation it. Isn't checking your data a 100 level concept? > > I'm guessing that On Error Resume Next is one of your friends too. > > Bob Lehmann > > "CMM" <cmm@nospam.com> wrote in message > news:%23h%23gzeNNGHA.1676@TK2MSFTNGP09.phx.gbl... >> I don't think that's true at all. First off, CStr,CBool, Etc. are all >> just >> easier-to-read specialized wrappers around CType..... which in and of > itself >> is a special "VB" construct. The true "non-VB" casting operator is >> DirectCast(...). >> >> Contrary to what Scott M says you're SUPPOSED to use them. What's the > point >> of using VB if you're not going to use its special methods that make your >> life easier? This is straight from the VB documentation: >> >> "As a rule, you should use the Visual Basic type conversion functions in >> preference to the .NET Framework methods such as ToString(), either on >> the >> Convert class or on an individual type structure or class. The Visual > Basic >> functions are designed for optimal interaction with Visual Basic code, >> and >> they also make your source code shorter and easier to read. In addition, > the >> .NET Framework conversion methods do not always produce the same results > as >> the Visual Basic functions, for example when converting Boolean to > Integer. >> For more information, see Troubleshooting Data Types." >> >> In addition, although I'm a guy who always initializes strings and >> objects >> as soon as possible rather than have them sit around until my algorithm > uses >> them- so I don't really care about the following- but, there's an > advantage >> to using VB's functions: they interpret "Nothing." You can't use the OO >> methods on a string that is "Nothing" (s.ToUpper for instance won't >> work). >> >> -- >> -C. Moya >> www.cmoya.com >> "Scott M." <s-mar@nospam.nospam> wrote in message >> news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... >> > IMHO (and this has been debated for quite some time now), you should > view >> > all of the old "data-type" specific functions as legacy functions and >> > no >> > longer use them. Instead, use the more object-oriented methods of a > type. >> > >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or >> > .ToString >> > All date/time functions would be replaced with methods and properties >> > of >> > the Date class >> > All string functions would be replaced with methods and properties of > the >> > String class. >> > >> > et all. >> > >> > >> > "Sean" <S***@discussions.microsoft.com> wrote in message >> > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... >> >> Book I am reading says that Cstr() is best method for efficency and >> >> safety >> >> however it doesnt compare that method of the .ToString() method. >> >> >> >> Which is best. >> >> >> >> Thanks >> >> >> >> >> > >> > >> >> > > >> Checking if a variable actually contains data before doing a convert .. is simply too much code.You aren't serious, are you? >> If you can avoid that it makes the code a lot better readable. You mean like the sentence above? I'm sure you meant "a lot more betterreadablest". Happy coding, pal. Bob Lehmann Show quoteHide quote "Martin" <x@y.com> wrote in message news:uuTEZGONGHA.1536@TK2MSFTNGP11.phx.gbl... > Wow, what happened to put you in this mood? > Checking if a variable actually contains data before doing a convert to > upper case is simply too much code. If you can avoid that it makes the code > a lot better readable. > > > "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message > news:epp0n5NNGHA.3856@TK2MSFTNGP12.phx.gbl... > >>> You can't use the OO methods on a string that is "Nothing" > > > > Why would you want to? > > > > Oh, I get it, you're too lazy to check the data before performing an > > operation it. Isn't checking your data a 100 level concept? > > > > I'm guessing that On Error Resume Next is one of your friends too. > > > > Bob Lehmann > > > > "CMM" <cmm@nospam.com> wrote in message > > news:%23h%23gzeNNGHA.1676@TK2MSFTNGP09.phx.gbl... > >> I don't think that's true at all. First off, CStr,CBool, Etc. are all > >> just > >> easier-to-read specialized wrappers around CType..... which in and of > > itself > >> is a special "VB" construct. The true "non-VB" casting operator is > >> DirectCast(...). > >> > >> Contrary to what Scott M says you're SUPPOSED to use them. What's the > > point > >> of using VB if you're not going to use its special methods that make your > >> life easier? This is straight from the VB documentation: > >> > >> "As a rule, you should use the Visual Basic type conversion functions in > >> preference to the .NET Framework methods such as ToString(), either on > >> the > >> Convert class or on an individual type structure or class. The Visual > > Basic > >> functions are designed for optimal interaction with Visual Basic code, > >> and > >> they also make your source code shorter and easier to read. In addition, > > the > >> .NET Framework conversion methods do not always produce the same results > > as > >> the Visual Basic functions, for example when converting Boolean to > > Integer. > >> For more information, see Troubleshooting Data Types." > >> > >> In addition, although I'm a guy who always initializes strings and > >> objects > >> as soon as possible rather than have them sit around until my algorithm > > uses > >> them- so I don't really care about the following- but, there's an > > advantage > >> to using VB's functions: they interpret "Nothing." You can't use the OO > >> methods on a string that is "Nothing" (s.ToUpper for instance won't > >> work). > >> > >> -- > >> -C. Moya > >> www.cmoya.com > >> "Scott M." <s-mar@nospam.nospam> wrote in message > >> news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... > >> > IMHO (and this has been debated for quite some time now), you should > > view > >> > all of the old "data-type" specific functions as legacy functions and > >> > no > >> > longer use them. Instead, use the more object-oriented methods of a > > type. > >> > > >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or > >> > .ToString > >> > All date/time functions would be replaced with methods and properties > >> > of > >> > the Date class > >> > All string functions would be replaced with methods and properties of > > the > >> > String class. > >> > > >> > et all. > >> > > >> > > >> > "Sean" <S***@discussions.microsoft.com> wrote in message > >> > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... > >> >> Book I am reading says that Cstr() is best method for efficency and > >> >> safety > >> >> however it doesnt compare that method of the .ToString() method. > >> >> > >> >> Which is best. > >> >> > >> >> Thanks > >> >> > >> >> > >> > > >> > > >> > >> > > > > > > Just wondering... Have you ever contibuted anything positive to this
newsgroup? (or to anything else) Show quoteHide quote "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message news:e6ugG1ONGHA.3944@tk2msftngp13.phx.gbl... >>> Checking if a variable actually contains data before doing a convert .. > is simply too much code. > You aren't serious, are you? > >>> If you can avoid that it makes the code a lot better readable. > You mean like the sentence above? I'm sure you meant "a lot more better > readablest". > > Happy coding, pal. > > Bob Lehmann > > "Martin" <x@y.com> wrote in message > news:uuTEZGONGHA.1536@TK2MSFTNGP11.phx.gbl... >> Wow, what happened to put you in this mood? >> Checking if a variable actually contains data before doing a convert to >> upper case is simply too much code. If you can avoid that it makes the > code >> a lot better readable. >> >> >> "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message >> news:epp0n5NNGHA.3856@TK2MSFTNGP12.phx.gbl... >> >>> You can't use the OO methods on a string that is "Nothing" >> > >> > Why would you want to? >> > >> > Oh, I get it, you're too lazy to check the data before performing an >> > operation it. Isn't checking your data a 100 level concept? >> > >> > I'm guessing that On Error Resume Next is one of your friends too. >> > >> > Bob Lehmann >> > >> > "CMM" <cmm@nospam.com> wrote in message >> > news:%23h%23gzeNNGHA.1676@TK2MSFTNGP09.phx.gbl... >> >> I don't think that's true at all. First off, CStr,CBool, Etc. are all >> >> just >> >> easier-to-read specialized wrappers around CType..... which in and of >> > itself >> >> is a special "VB" construct. The true "non-VB" casting operator is >> >> DirectCast(...). >> >> >> >> Contrary to what Scott M says you're SUPPOSED to use them. What's the >> > point >> >> of using VB if you're not going to use its special methods that make > your >> >> life easier? This is straight from the VB documentation: >> >> >> >> "As a rule, you should use the Visual Basic type conversion functions > in >> >> preference to the .NET Framework methods such as ToString(), either on >> >> the >> >> Convert class or on an individual type structure or class. The Visual >> > Basic >> >> functions are designed for optimal interaction with Visual Basic code, >> >> and >> >> they also make your source code shorter and easier to read. In > addition, >> > the >> >> .NET Framework conversion methods do not always produce the same > results >> > as >> >> the Visual Basic functions, for example when converting Boolean to >> > Integer. >> >> For more information, see Troubleshooting Data Types." >> >> >> >> In addition, although I'm a guy who always initializes strings and >> >> objects >> >> as soon as possible rather than have them sit around until my >> >> algorithm >> > uses >> >> them- so I don't really care about the following- but, there's an >> > advantage >> >> to using VB's functions: they interpret "Nothing." You can't use the >> >> OO >> >> methods on a string that is "Nothing" (s.ToUpper for instance won't >> >> work). >> >> >> >> -- >> >> -C. Moya >> >> www.cmoya.com >> >> "Scott M." <s-mar@nospam.nospam> wrote in message >> >> news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... >> >> > IMHO (and this has been debated for quite some time now), you should >> > view >> >> > all of the old "data-type" specific functions as legacy functions >> >> > and >> >> > no >> >> > longer use them. Instead, use the more object-oriented methods of a >> > type. >> >> > >> >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or >> >> > .ToString >> >> > All date/time functions would be replaced with methods and >> >> > properties >> >> > of >> >> > the Date class >> >> > All string functions would be replaced with methods and properties >> >> > of >> > the >> >> > String class. >> >> > >> >> > et all. >> >> > >> >> > >> >> > "Sean" <S***@discussions.microsoft.com> wrote in message >> >> > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... >> >> >> Book I am reading says that Cstr() is best method for efficency and >> >> >> safety >> >> >> however it doesnt compare that method of the .ToString() method. >> >> >> >> >> >> Which is best. >> >> >> >> >> >> Thanks >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> >> > >> > >> >> > > >> Have you ever contibuted anything positive I suggested that checking your data before performing operations the data isUh, yeah. a best practice. I highly doubt that any competent programmer would disagree. Apparently you are not in that group. Or, is your specialty in buffer overruns? At least you have a sound rationale - "Checking if a variable actually contains data before doing a convert to upper case is simply too much code." Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo hard to do. And besides, my code is better readable since you know I don't indent If blocks. Perhaps you should stick to scripting languages where you don't have all the icky typed variable stuff going on. I mean, isn't it a hassle declaring all those variable thingys, with all that code and stuff? Maybe, after you've completed Junior High, you'll have a different perspective. >> (or to anything else) Yes, I don't write malware.Bob Lehmann Show quoteHide quote "Martin" <x@y.com> wrote in message news:eFF6lBPNGHA.536@TK2MSFTNGP09.phx.gbl... > Just wondering... Have you ever contibuted anything positive to this > newsgroup? (or to anything else) > > > "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message > news:e6ugG1ONGHA.3944@tk2msftngp13.phx.gbl... > >>> Checking if a variable actually contains data before doing a convert ... > > is simply too much code. > > You aren't serious, are you? > > > >>> If you can avoid that it makes the code a lot better readable. > > You mean like the sentence above? I'm sure you meant "a lot more better > > readablest". > > > > Happy coding, pal. > > > > Bob Lehmann > > > > "Martin" <x@y.com> wrote in message > > news:uuTEZGONGHA.1536@TK2MSFTNGP11.phx.gbl... > >> Wow, what happened to put you in this mood? > >> Checking if a variable actually contains data before doing a convert to > >> upper case is simply too much code. If you can avoid that it makes the > > code > >> a lot better readable. > >> > >> > >> "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message > >> news:epp0n5NNGHA.3856@TK2MSFTNGP12.phx.gbl... > >> >>> You can't use the OO methods on a string that is "Nothing" > >> > > >> > Why would you want to? > >> > > >> > Oh, I get it, you're too lazy to check the data before performing an > >> > operation it. Isn't checking your data a 100 level concept? > >> > > >> > I'm guessing that On Error Resume Next is one of your friends too. > >> > > >> > Bob Lehmann > >> > > >> > "CMM" <cmm@nospam.com> wrote in message > >> > news:%23h%23gzeNNGHA.1676@TK2MSFTNGP09.phx.gbl... > >> >> I don't think that's true at all. First off, CStr,CBool, Etc. are all > >> >> just > >> >> easier-to-read specialized wrappers around CType..... which in and of > >> > itself > >> >> is a special "VB" construct. The true "non-VB" casting operator is > >> >> DirectCast(...). > >> >> > >> >> Contrary to what Scott M says you're SUPPOSED to use them. What's the > >> > point > >> >> of using VB if you're not going to use its special methods that make > > your > >> >> life easier? This is straight from the VB documentation: > >> >> > >> >> "As a rule, you should use the Visual Basic type conversion functions > > in > >> >> preference to the .NET Framework methods such as ToString(), either on > >> >> the > >> >> Convert class or on an individual type structure or class. The Visual > >> > Basic > >> >> functions are designed for optimal interaction with Visual Basic code, > >> >> and > >> >> they also make your source code shorter and easier to read. In > > addition, > >> > the > >> >> .NET Framework conversion methods do not always produce the same > > results > >> > as > >> >> the Visual Basic functions, for example when converting Boolean to > >> > Integer. > >> >> For more information, see Troubleshooting Data Types." > >> >> > >> >> In addition, although I'm a guy who always initializes strings and > >> >> objects > >> >> as soon as possible rather than have them sit around until my > >> >> algorithm > >> > uses > >> >> them- so I don't really care about the following- but, there's an > >> > advantage > >> >> to using VB's functions: they interpret "Nothing." You can't use the > >> >> OO > >> >> methods on a string that is "Nothing" (s.ToUpper for instance won't > >> >> work). > >> >> > >> >> -- > >> >> -C. Moya > >> >> www.cmoya.com > >> >> "Scott M." <s-mar@nospam.nospam> wrote in message > >> >> news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... > >> >> > IMHO (and this has been debated for quite some time now), you should > >> > view > >> >> > all of the old "data-type" specific functions as legacy functions > >> >> > and > >> >> > no > >> >> > longer use them. Instead, use the more object-oriented methods of a > >> > type. > >> >> > > >> >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or > >> >> > .ToString > >> >> > All date/time functions would be replaced with methods and > >> >> > properties > >> >> > of > >> >> > the Date class > >> >> > All string functions would be replaced with methods and properties > >> >> > of > >> > the > >> >> > String class. > >> >> > > >> >> > et all. > >> >> > > >> >> > > >> >> > "Sean" <S***@discussions.microsoft.com> wrote in message > >> >> > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... > >> >> >> Book I am reading says that Cstr() is best method for efficency and > >> >> >> safety > >> >> >> however it doesnt compare that method of the .ToString() method. > >> >> >> > >> >> >> Which is best. > >> >> >> > >> >> >> Thanks > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > >> >> > >> > > >> > > >> > >> > > > > > > Finishing junior high may be your problem. I have a real education ;-)
Show quoteHide quote "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message news:ubhnniPNGHA.3276@TK2MSFTNGP09.phx.gbl... >>> Have you ever contibuted anything positive > Uh, yeah. > > I suggested that checking your data before performing operations the data > is > a best practice. I highly doubt that any competent programmer would > disagree. Apparently you are not in that group. > > Or, is your specialty in buffer overruns? > > At least you have a sound rationale - > "Checking if a variable actually contains data before doing a convert to > upper case is simply too much code." > > Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo > hard > to do. And besides, my code is better readable since you know I don't > indent > If blocks. > > Perhaps you should stick to scripting languages where you don't have all > the > icky typed variable stuff going on. I mean, isn't it a hassle declaring > all > those variable thingys, with all that code and stuff? > > Maybe, after you've completed Junior High, you'll have a different > perspective. > >>> (or to anything else) > Yes, I don't write malware. > > Bob Lehmann > > "Martin" <x@y.com> wrote in message > news:eFF6lBPNGHA.536@TK2MSFTNGP09.phx.gbl... >> Just wondering... Have you ever contibuted anything positive to this >> newsgroup? (or to anything else) >> >> >> "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message >> news:e6ugG1ONGHA.3944@tk2msftngp13.phx.gbl... >> >>> Checking if a variable actually contains data before doing a convert > .. >> > is simply too much code. >> > You aren't serious, are you? >> > >> >>> If you can avoid that it makes the code a lot better readable. >> > You mean like the sentence above? I'm sure you meant "a lot more better >> > readablest". >> > >> > Happy coding, pal. >> > >> > Bob Lehmann >> > >> > "Martin" <x@y.com> wrote in message >> > news:uuTEZGONGHA.1536@TK2MSFTNGP11.phx.gbl... >> >> Wow, what happened to put you in this mood? >> >> Checking if a variable actually contains data before doing a convert >> >> to >> >> upper case is simply too much code. If you can avoid that it makes the >> > code >> >> a lot better readable. >> >> >> >> >> >> "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message >> >> news:epp0n5NNGHA.3856@TK2MSFTNGP12.phx.gbl... >> >> >>> You can't use the OO methods on a string that is "Nothing" >> >> > >> >> > Why would you want to? >> >> > >> >> > Oh, I get it, you're too lazy to check the data before performing an >> >> > operation it. Isn't checking your data a 100 level concept? >> >> > >> >> > I'm guessing that On Error Resume Next is one of your friends too. >> >> > >> >> > Bob Lehmann >> >> > >> >> > "CMM" <cmm@nospam.com> wrote in message >> >> > news:%23h%23gzeNNGHA.1676@TK2MSFTNGP09.phx.gbl... >> >> >> I don't think that's true at all. First off, CStr,CBool, Etc. are > all >> >> >> just >> >> >> easier-to-read specialized wrappers around CType..... which in and > of >> >> > itself >> >> >> is a special "VB" construct. The true "non-VB" casting operator is >> >> >> DirectCast(...). >> >> >> >> >> >> Contrary to what Scott M says you're SUPPOSED to use them. What's > the >> >> > point >> >> >> of using VB if you're not going to use its special methods that >> >> >> make >> > your >> >> >> life easier? This is straight from the VB documentation: >> >> >> >> >> >> "As a rule, you should use the Visual Basic type conversion > functions >> > in >> >> >> preference to the .NET Framework methods such as ToString(), either > on >> >> >> the >> >> >> Convert class or on an individual type structure or class. The > Visual >> >> > Basic >> >> >> functions are designed for optimal interaction with Visual Basic > code, >> >> >> and >> >> >> they also make your source code shorter and easier to read. In >> > addition, >> >> > the >> >> >> .NET Framework conversion methods do not always produce the same >> > results >> >> > as >> >> >> the Visual Basic functions, for example when converting Boolean to >> >> > Integer. >> >> >> For more information, see Troubleshooting Data Types." >> >> >> >> >> >> In addition, although I'm a guy who always initializes strings and >> >> >> objects >> >> >> as soon as possible rather than have them sit around until my >> >> >> algorithm >> >> > uses >> >> >> them- so I don't really care about the following- but, there's an >> >> > advantage >> >> >> to using VB's functions: they interpret "Nothing." You can't use >> >> >> the >> >> >> OO >> >> >> methods on a string that is "Nothing" (s.ToUpper for instance won't >> >> >> work). >> >> >> >> >> >> -- >> >> >> -C. Moya >> >> >> www.cmoya.com >> >> >> "Scott M." <s-mar@nospam.nospam> wrote in message >> >> >> news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... >> >> >> > IMHO (and this has been debated for quite some time now), you > should >> >> > view >> >> >> > all of the old "data-type" specific functions as legacy functions >> >> >> > and >> >> >> > no >> >> >> > longer use them. Instead, use the more object-oriented methods >> >> >> > of > a >> >> > type. >> >> >> > >> >> >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or >> >> >> > .ToString >> >> >> > All date/time functions would be replaced with methods and >> >> >> > properties >> >> >> > of >> >> >> > the Date class >> >> >> > All string functions would be replaced with methods and >> >> >> > properties >> >> >> > of >> >> > the >> >> >> > String class. >> >> >> > >> >> >> > et all. >> >> >> > >> >> >> > >> >> >> > "Sean" <S***@discussions.microsoft.com> wrote in message >> >> >> > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... >> >> >> >> Book I am reading says that Cstr() is best method for efficency > and >> >> >> >> safety >> >> >> >> however it doesnt compare that method of the .ToString() method. >> >> >> >> >> >> >> >> Which is best. >> >> >> >> >> >> >> >> Thanks >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> >> > >> > >> >> > > >> I have a real education Which you have demonstrated, admirably.Bob Lehmann Show quoteHide quote "Martin" <x@y.com> wrote in message news:%234mfTnPNGHA.3936@TK2MSFTNGP12.phx.gbl... > Finishing junior high may be your problem. I have a real education ;-) > > "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message > news:ubhnniPNGHA.3276@TK2MSFTNGP09.phx.gbl... > >>> Have you ever contibuted anything positive > > Uh, yeah. > > > > I suggested that checking your data before performing operations the data > > is > > a best practice. I highly doubt that any competent programmer would > > disagree. Apparently you are not in that group. > > > > Or, is your specialty in buffer overruns? > > > > At least you have a sound rationale - > > "Checking if a variable actually contains data before doing a convert to > > upper case is simply too much code." > > > > Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo > > hard > > to do. And besides, my code is better readable since you know I don't > > indent > > If blocks. > > > > Perhaps you should stick to scripting languages where you don't have all > > the > > icky typed variable stuff going on. I mean, isn't it a hassle declaring > > all > > those variable thingys, with all that code and stuff? > > > > Maybe, after you've completed Junior High, you'll have a different > > perspective. > > > >>> (or to anything else) > > Yes, I don't write malware. > > > > Bob Lehmann > > > > "Martin" <x@y.com> wrote in message > > news:eFF6lBPNGHA.536@TK2MSFTNGP09.phx.gbl... > >> Just wondering... Have you ever contibuted anything positive to this > >> newsgroup? (or to anything else) > >> > >> > >> "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message > >> news:e6ugG1ONGHA.3944@tk2msftngp13.phx.gbl... > >> >>> Checking if a variable actually contains data before doing a convert > > .. > >> > is simply too much code. > >> > You aren't serious, are you? > >> > > >> >>> If you can avoid that it makes the code a lot better readable. > >> > You mean like the sentence above? I'm sure you meant "a lot more better > >> > readablest". > >> > > >> > Happy coding, pal. > >> > > >> > Bob Lehmann > >> > > >> > "Martin" <x@y.com> wrote in message > >> > news:uuTEZGONGHA.1536@TK2MSFTNGP11.phx.gbl... > >> >> Wow, what happened to put you in this mood? > >> >> Checking if a variable actually contains data before doing a convert > >> >> to > >> >> upper case is simply too much code. If you can avoid that it makes the > >> > code > >> >> a lot better readable. > >> >> > >> >> > >> >> "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message > >> >> news:epp0n5NNGHA.3856@TK2MSFTNGP12.phx.gbl... > >> >> >>> You can't use the OO methods on a string that is "Nothing" > >> >> > > >> >> > Why would you want to? > >> >> > > >> >> > Oh, I get it, you're too lazy to check the data before performing an > >> >> > operation it. Isn't checking your data a 100 level concept? > >> >> > > >> >> > I'm guessing that On Error Resume Next is one of your friends too. > >> >> > > >> >> > Bob Lehmann > >> >> > > >> >> > "CMM" <cmm@nospam.com> wrote in message > >> >> > news:%23h%23gzeNNGHA.1676@TK2MSFTNGP09.phx.gbl... > >> >> >> I don't think that's true at all. First off, CStr,CBool, Etc. are > > all > >> >> >> just > >> >> >> easier-to-read specialized wrappers around CType..... which in and > > of > >> >> > itself > >> >> >> is a special "VB" construct. The true "non-VB" casting operator is > >> >> >> DirectCast(...). > >> >> >> > >> >> >> Contrary to what Scott M says you're SUPPOSED to use them. What's > > the > >> >> > point > >> >> >> of using VB if you're not going to use its special methods that > >> >> >> make > >> > your > >> >> >> life easier? This is straight from the VB documentation: > >> >> >> > >> >> >> "As a rule, you should use the Visual Basic type conversion > > functions > >> > in > >> >> >> preference to the .NET Framework methods such as ToString(), either > > on > >> >> >> the > >> >> >> Convert class or on an individual type structure or class. The > > Visual > >> >> > Basic > >> >> >> functions are designed for optimal interaction with Visual Basic > > code, > >> >> >> and > >> >> >> they also make your source code shorter and easier to read. In > >> > addition, > >> >> > the > >> >> >> .NET Framework conversion methods do not always produce the same > >> > results > >> >> > as > >> >> >> the Visual Basic functions, for example when converting Boolean to > >> >> > Integer. > >> >> >> For more information, see Troubleshooting Data Types." > >> >> >> > >> >> >> In addition, although I'm a guy who always initializes strings and > >> >> >> objects > >> >> >> as soon as possible rather than have them sit around until my > >> >> >> algorithm > >> >> > uses > >> >> >> them- so I don't really care about the following- but, there's an > >> >> > advantage > >> >> >> to using VB's functions: they interpret "Nothing." You can't use > >> >> >> the > >> >> >> OO > >> >> >> methods on a string that is "Nothing" (s.ToUpper for instance won't > >> >> >> work). > >> >> >> > >> >> >> -- > >> >> >> -C. Moya > >> >> >> www.cmoya.com > >> >> >> "Scott M." <s-mar@nospam.nospam> wrote in message > >> >> >> news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... > >> >> >> > IMHO (and this has been debated for quite some time now), you > > should > >> >> > view > >> >> >> > all of the old "data-type" specific functions as legacy functions > >> >> >> > and > >> >> >> > no > >> >> >> > longer use them. Instead, use the more object-oriented methods > >> >> >> > of > > a > >> >> > type. > >> >> >> > > >> >> >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or > >> >> >> > .ToString > >> >> >> > All date/time functions would be replaced with methods and > >> >> >> > properties > >> >> >> > of > >> >> >> > the Date class > >> >> >> > All string functions would be replaced with methods and > >> >> >> > properties > >> >> >> > of > >> >> > the > >> >> >> > String class. > >> >> >> > > >> >> >> > et all. > >> >> >> > > >> >> >> > > >> >> >> > "Sean" <S***@discussions.microsoft.com> wrote in message > >> >> >> > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... > >> >> >> >> Book I am reading says that Cstr() is best method for efficency > > and > >> >> >> >> safety > >> >> >> >> however it doesnt compare that method of the .ToString() method. > >> >> >> >> > >> >> >> >> Which is best. > >> >> >> >> > >> >> >> >> Thanks > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > >> >> > >> > > >> > > >> > >> > > > > > > "Bob Lehmann" <nospam@dontbotherme.zzz> schrieb: Well, why duplicate this checking code all over the source code if it is > At least you have a sound rationale - > "Checking if a variable actually contains data before doing a convert to > upper case is simply too much code." > > Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo > hard > to do. And besides, my code is better readable since you know I don't > indent > If blocks. possible to encapsulate it cleanly in high-level wrappers/functions like 'CStr'? -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> Because CStr() wouldn't throw an exception if it encountered a Nothing
value, which could cause unexpected bugs in the application. ToString would throw an exception and thus make it easier to determine the problem. Show quoteHide quote "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:uYAx7yVNGHA.456@TK2MSFTNGP15.phx.gbl... > "Bob Lehmann" <nospam@dontbotherme.zzz> schrieb: >> At least you have a sound rationale - >> "Checking if a variable actually contains data before doing a convert to >> upper case is simply too much code." >> >> Waaaaa! But Mom, those extra 20 keystrokes to check the data are soooo >> hard >> to do. And besides, my code is better readable since you know I don't >> indent >> If blocks. > > Well, why duplicate this checking code all over the source code if it is > possible to encapsulate it cleanly in high-level wrappers/functions like > 'CStr'? > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/> "Scott M." <s-mar@nospam.nospam> schrieb: Well, but there are cases where I'd call 'CStr' intentionally because I want > Because CStr() wouldn't throw an exception if it encountered a Nothing > value, which could cause unexpected bugs in the application. ToString > would throw an exception and thus make it easier to determine the problem. a 'Nothing' reference to be converted to an empty string! -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> I hear what you are saying, but as I said in the previous post, using CStr()
wouldn't allow you to discriminate between those Nothing values that you intended to run across and Nothing values that inadvertantly may happen. As others have said, a simple If statement that checks for the Nothing value would allow you to get a Nothing value and convert it to an empty string while still maintaining the integrety of the code. Show quoteHide quote "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:uu3XlOXNGHA.964@tk2msftngp13.phx.gbl... > "Scott M." <s-mar@nospam.nospam> schrieb: >> Because CStr() wouldn't throw an exception if it encountered a Nothing >> value, which could cause unexpected bugs in the application. ToString >> would throw an exception and thus make it easier to determine the >> problem. > > Well, but there are cases where I'd call 'CStr' intentionally because I > want a 'Nothing' reference to be converted to an empty string! > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/> "Scott M." <s-mar@nospam.nospam> schrieb: 'CStr' is different from 'ToString'. It's obvious that it doesn't behave >I hear what you are saying, but as I said in the previous post, using >CStr() wouldn't allow you to discriminate between those Nothing values that >you intended to run across and Nothing values that inadvertantly may >happen. As others have said, a simple If statement that checks for the >Nothing value would allow you to get a Nothing value and convert it to an >empty string while still maintaining the integrety of the code. like 'ToString', and the additional behavior is publically well-known. So using 'CStr' *iff* it makes sense does not break the integrity of the code. It's the developer's fault if it breaks integrity. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> >So using 'CStr' *iff* it makes sense does not break the integrity of the Well, yeah! Yiou seem to now agree with me that using CStr() doesn't >code. > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/> *always* make sense. That's all I've been trying to say...CStr() can get you into trouble in certain situations. And when it does, it can be difficult to troubleshoot where the problem is due to the *valid*, but empty string floating around in memory. ToString can get you into trouble as well, but it's a whole lot easier to see where the problem is in the ToString scenario. And if you want to avoid the empty string possibility of CStr(), you are going to need an IF statement to check the string, just as you would need to check the string for Nothing using ToString, so there's no code savings that others have indicated there would be. As for the additional behavior of CStr() being well known, I highly disagree. This whole thread (and countless others) started off with the OP confused over the difference between CStr() and .ToString. "Scott M." <s-mar@nospam.nospam> schrieb: Well, I'm glad we agree on this point too :-).> >So using 'CStr' *iff* it makes sense does not break the integrity of the > >code. > Well, yeah! Yiou seem to now agree with me that using CStr() doesn't > *always* make sense. That's all I've been trying to say...CStr() can get > you into trouble in certain situations. > As for the additional behavior of CStr() being well known, I highly I think this problem always arises if people are using tools they do not > disagree. This whole thread (and countless others) started off with the > OP confused over the difference between CStr() and .ToString. fully understand. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> >> think this problem always arises if people are using tools they do not Which could be avoided if best practices were followed to begin with, andfully understand. not fueled by bad advice. Bob Lehmann Show quoteHide quote "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:OCAf7waNGHA.1028@TK2MSFTNGP11.phx.gbl... > "Scott M." <s-mar@nospam.nospam> schrieb: > > >So using 'CStr' *iff* it makes sense does not break the integrity of the > > >code. > > Well, yeah! Yiou seem to now agree with me that using CStr() doesn't > > *always* make sense. That's all I've been trying to say...CStr() can get > > you into trouble in certain situations. > > Well, I'm glad we agree on this point too :-). > > > As for the additional behavior of CStr() being well known, I highly > > disagree. This whole thread (and countless others) started off with the > > OP confused over the difference between CStr() and .ToString. > > I think this problem always arises if people are using tools they do not > fully understand. > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/> > Yes and then the question is who defines the best practices and guidelines
??? cause past week i showed some examples from the best practices and guidelines book i have ( oficial MS press book written by the core reference writer ) and you should have seen the thread :-) so question is ........ who defines this then ,,,,, every sole developer for himself apperently ,,,, so in the end we stay with the same coding mess regards M. Posseth [MCP] Show quoteHide quote "Bob Lehmann" <nospam@dontbotherme.zzz> schreef in bericht news:u%23VK5CcNGHA.420@tk2msftngp13.phx.gbl... >>> think this problem always arises if people are using tools they do not > fully understand. > > Which could be avoided if best practices were followed to begin with, and > not fueled by bad advice. > > Bob Lehmann > > "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message > news:OCAf7waNGHA.1028@TK2MSFTNGP11.phx.gbl... >> "Scott M." <s-mar@nospam.nospam> schrieb: >> > >So using 'CStr' *iff* it makes sense does not break the integrity of > the >> > >code. >> > Well, yeah! Yiou seem to now agree with me that using CStr() doesn't >> > *always* make sense. That's all I've been trying to say...CStr() can > get >> > you into trouble in certain situations. >> >> Well, I'm glad we agree on this point too :-). >> >> > As for the additional behavior of CStr() being well known, I highly >> > disagree. This whole thread (and countless others) started off with >> > the >> > OP confused over the difference between CStr() and .ToString. >> >> I think this problem always arises if people are using tools they do not >> fully understand. >> >> -- >> M S Herfried K. Wagner >> M V P <URL:http://dotnet.mvps.org/> >> V B <URL:http://classicvb.org/petition/> >> > > "Bob Lehmann" <nospam@dontbotherme.zzz> schrieb: Using 'CStr' whenever it /makes sense/ is good practice.>>> think this problem always arises if people are using tools they do not >>> fully understand. > > Which could be avoided if best practices were followed to begin with, and > not fueled by bad advice. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message Always has been always will be. If one doesn't like VB's specialized helper > Using 'CStr' whenever it /makes sense/ is good practice. functions and methods, maybe they shouldn't be coding in VB. And, to call them "legacy" is both ignorant and shortsighted. They are what make VB "VB." Chances are at some point people like Scott M will realize what "encapsulation" means and write their own SafeToString(object) helper function... not really realizing (or caring) that they had this all along. Wow, you are just full of compliments CMM. Read the first 4 letters I wrote
in my OP. If I told you that I always want to treat a Nothing value differently than a String value, what would you suggest I do? Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:u6BhIJhNGHA.3732@TK2MSFTNGP10.phx.gbl... > "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message >> Using 'CStr' whenever it /makes sense/ is good practice. > > Always has been always will be. If one doesn't like VB's specialized > helper functions and methods, maybe they shouldn't be coding in VB. And, > to call them "legacy" is both ignorant and shortsighted. They are what > make VB "VB." > > Chances are at some point people like Scott M will realize what > "encapsulation" means and write their own SafeToString(object) helper > function... not really realizing (or caring) that they had this all along. > > -- > -C. Moya > www.cmoya.com > > SafeGetString(object, valueIfNothing) As String
Encapsulation, my friend. It's a great practice. I don't disagree at all, but now SafeGetString does what I want, it is an
object method and is not in danger of being deprecated at some point, right? Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:euVnHdiNGHA.1124@TK2MSFTNGP10.phx.gbl... > SafeGetString(object, valueIfNothing) As String > > Encapsulation, my friend. It's a great practice. > > -- > -C. Moya > www.cmoya.com > Where'd you get this notion that VB's functions will be deprecated at some
point? MS Engineers that have been working for 5 years now with the companies I do
business with. Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:u9pKcujNGHA.3576@TK2MSFTNGP15.phx.gbl... > Where'd you get this notion that VB's functions will be deprecated at some > point? > > -- > -C. Moya > www.cmoya.com > > > I'd venture to say that these "MS engineers" (actually you said
"consultants" in another post, right?) are 100% wrong, misinformed, or (more likely) C# programmers commissioned to give advice on "VB." These consultants are usually contracted through 3rd parties, hired cheap, and are by no means authoritive. There is no way VB will lose its inline casting conversions just like CSharp won't. There is no way VB will lose its VB-specific methods until the day the framework actually provides equivalent functionality (i.e. String.Substring() is a LESSER function than Left/Right/Mid as I have already demonstrated in another post). Show quoteHide quote "Scott M." <s-mar@nospam.nospam> wrote in message news:%232nmW6jNGHA.668@TK2MSFTNGP11.phx.gbl... > MS Engineers that have been working for 5 years now with the companies I > do business with. > > > "CMM" <cmm@nospam.com> wrote in message > news:u9pKcujNGHA.3576@TK2MSFTNGP15.phx.gbl... >> Where'd you get this notion that VB's functions will be deprecated at >> some >> point? >> >> -- >> -C. Moya >> www.cmoya.com >> >> >> > > No. These are MS Engineers employed directly by MS and contracted out to
the companies I do business with (hence the term contractors earlier). Their services were retained directly from MS to aid in the development of company policies/best practices and the best way to convert VB 6.0 code to VB .NET. Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:Ou1n0CkNGHA.1216@TK2MSFTNGP14.phx.gbl... > I'd venture to say that these "MS engineers" (actually you said > "consultants" in another post, right?) are 100% wrong, misinformed, or > (more likely) C# programmers commissioned to give advice on "VB." These > consultants are usually contracted through 3rd parties, hired cheap, and > are by no means authoritive. There is no way VB will lose its inline > casting conversions just like CSharp won't. There is no way VB will lose > its VB-specific methods until the day the framework actually provides > equivalent functionality (i.e. String.Substring() is a LESSER function > than Left/Right/Mid as I have already demonstrated in another post). > > -- > -C. Moya > www.cmoya.com > "Scott M." <s-mar@nospam.nospam> wrote in message > news:%232nmW6jNGHA.668@TK2MSFTNGP11.phx.gbl... >> MS Engineers that have been working for 5 years now with the companies I >> do business with. >> >> >> "CMM" <cmm@nospam.com> wrote in message >> news:u9pKcujNGHA.3576@TK2MSFTNGP15.phx.gbl... >>> Where'd you get this notion that VB's functions will be deprecated at >>> some >>> point? >>> >>> -- >>> -C. Moya >>> www.cmoya.com >>> >>> >>> >> >> > > I once had to upgrade a VB5/6 CRM application written by these "MS
engineers" where they would import the WSH library to do ONE simple file operation apparently oblivious that they could accomplish the same EXACT thing using VB's intrinsic methods. WSH caused problems with deployment because not all machines (many NT, only a few 2000) had it installed and WSH was notoriously difficult to deploy at the time.... there was no redistributable for it. Big HEADACHE. Solved easily when I rewrote the algorithm using VB's built-in methods. Nothing lost. Lots gained. That's a nice story. How is it relevant to the thread?
Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:u$ej$vnNGHA.3944@tk2msftngp13.phx.gbl... >I once had to upgrade a VB5/6 CRM application written by these "MS >engineers" where they would import the WSH library to do ONE simple file >operation apparently oblivious that they could accomplish the same EXACT >thing using VB's intrinsic methods. WSH caused problems with deployment >because not all machines (many NT, only a few 2000) had it installed and >WSH was notoriously difficult to deploy at the time.... there was no >redistributable for it. > > Big HEADACHE. Solved easily when I rewrote the algorithm using VB's > built-in methods. Nothing lost. Lots gained. > > -- > -C. Moya > www.cmoya.com > It shows that just because your so-called "MS Engineers" (consultants, hired
for cheap in my opinion) say one thing doesn't mean its correct. Those guys aren't the VB Language Development Team. If you were to cite a VB Language Development Team member say VB's high-level superset functions will be deprecated then THAT's a different story and I will HAPPILY eat my words. As it stands right now, you haven't proved any point at all... and have instead cited dubious observations and generalizations based on nothing at all except your own uninformed misunderstanding of general language constructs, the framework in general, and VB in particular. In short your original statement that these operators and functions (CStr/Cint/etc operators... and the wrapper functions like Len,Left,Split, etc etc) are LEGACY is 100% wrong.... and, yes, a stupid assertion. Stupid not because you're stupid, but because it is an assertion based on no evidence or knowledge whatsover and flies in the face of all current evidence and history. "Scott M." <s-mar@nospam.nospam> schrieb: Well, maybe those MS engineers are disguised C#ies. I do not see any > MS Engineers that have been working for 5 years now with the companies I > do business with. evidence for the deprecation of VB's function library because deprecating it is only a lose situation (the library is well-tested and used in most of the existing code and newly written projects). -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> Scott,
"Scott M." <s-mar@nospam.nospam> schrieb: I am wondering how you come to the perception that everything bust be an >> SafeGetString(object, valueIfNothing) As String >> >> Encapsulation, my friend. It's a great practice. > >I don't disagree at all, but now SafeGetString does what I want, it is an >object method and is not in danger of being deprecated at some point, >right? "object method". OO is just one of the tools available in VB.NET's toolbox. Modules are a good thing (except that they get imported automatically) because they provide a semantically correct and suitable grouping container for methods which semantically belong to each other but do not form an entity. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> > I am wondering how you come to the perception that everything bust be an I never said it should be. I said (for the umpteenth time) the I *prefer* > "object method". to use ToString because it is a more OO way of writing the code. The responses were about the merits of CStr() and one of the things stated about it was that it is an OO way of writing the code. I disagreed with that point. I have said over and over that this is my *preference* and I've given my reasons for why. If you disagree fine, but please don't put words in my mouth. > > SafeGetString(object, valueIfNothing) As String Okay, I'm now confused. How is SafeGetString an object method? I> > I don't disagree at all, but now SafeGetString does what I want, it is an > object method and is not in danger of being deprecated at some point, right? thought an object method was a method OF AN OBJECT...like myString.ToString() which you've all been talking about. >From what I understand (I came from PowerBuilder and VB6, so I know OO from PB, and I know the syntax of VB6), objects are just a part of theframework. The whole framework isn't an object. Just cause you can use dot notation doesn't make it an object. Unless you actually have an instance of some object you are just calling methods/whatever of the platform (language syntax). Encapsulation doesn't have anything to do with that SafeGetString function...right? Matt "YYZ" <matt.da***@gmail.com> schrieb: Encapsulation is not only about encapsulating things in classes. It's the > Encapsulation doesn't have anything to do with that SafeGetString > function...right? general concept of encapsulating functionality in entities, which can be procedures or classes, for example. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> > Encapsulation is not only about encapsulating things in classes. It's the I'm not sure I follow this...but are you saying that you would/could> general concept of encapsulating functionality in entities, which can be > procedures or classes, for example. create a module of string functions, and that you would encapsulate this method inside that module? I honestly am not following how SafeGetString falls into encapsulation. Matt It fulfills the encapsulation rule because it replaces the dozens of
conditionals that would otherwise litter "bad code." It doesn't matter if it's a shared method in a class or a public method in a BASIC Module. It's encapsulation. Just like CStr fulfills the encapsulation ideal. In this case it's conversion operator not a function. Matt,
SafeGetString would be declared as a Shared Function of some Public class so you wouldn't need an instance of it, but you would more likely call it as someObject.SafeGetString(). Show quoteHide quote "YYZ" <matt.da***@gmail.com> wrote in message news:1140468767.792380.274870@g44g2000cwa.googlegroups.com... >> > SafeGetString(object, valueIfNothing) As String >> >> I don't disagree at all, but now SafeGetString does what I want, it is an >> object method and is not in danger of being deprecated at some point, >> right? > > Okay, I'm now confused. How is SafeGetString an object method? I > thought an object method was a method OF AN OBJECT...like > myString.ToString() which you've all been talking about. > >>From what I understand (I came from PowerBuilder and VB6, so I know OO > from PB, and I know the syntax of VB6), objects are just a part of the > framework. The whole framework isn't an object. Just cause you can > use dot notation doesn't make it an object. Unless you actually have > an instance of some object you are just calling methods/whatever of the > platform (language syntax). > > Encapsulation doesn't have anything to do with that SafeGetString > function...right? > > Matt > And making it a global function in a VB "Module" as opposed to making it a
Shared Method of a class doesn't make it any less OO either. Just like the "System" namespace being globally accessible doesn't make using it any less OO. > SafeGetString would be declared as a Shared Function of some Public class so Ahh. That is definitely NOT how I would do it. I would put it into my> you wouldn't need an instance of it, but you would more likely call it as > someObject.SafeGetString(). multipurpose modGenericFunctions module -- not a class, but a collection fo subs/procedures/etc that I put into almost every program. I actually think of this module as "Matt's Extra Language Keywords" Meaning, things I wish .Net (or any language) had by default. With VB6, I had this thing up to a about 50 or so functions, but in .Net it's only about 20. I'll keep adding to it as the need arises. Your logic in this instance reminds me of some holy war type discussions I've seen on many newsgroups -- the one about global variables. I've seen people who say that "global variables are evil! They should never be used...EVER!" and then go on to give advice to create a class with properties such as UserId and Password and then create one global instance of that class, and refer to that class object's properties where they need a global variable -- uh....those are STILL global variables... I'm not saying that is your perspective, it just reminded me of that. I think you are saying that you should have a class with a SafeGetString method and then have to create a global object of that class (or local...whatever) when you need to use it...is that what you are saying? As an aside, I have a function that use called ReturnDouble -- it can take in anything (via overloads) and will always return a number -- it will return 0 if what was passed in can't be read to a number. Just like Cstr returning "" if it can't find a real string in what was passed. I bet that this has saved me hundreds of hours over the years. No longer do I ever have to worry about what is contained in a variable or a textbox or whatever...I can confidently use it in equations all over the place. I code for what USUALLY happens, and then make expceptions to that, just that, an exception to normal programming. Matt And you're doing just fine YYZ.
Holy wars--- especially in the VisualBasic world for some reason--- are usually based on deep-seated misunderstandings. Like, the new one I just heard that the Framework is the end-all-and-be-all and if it's not in it, then it shouldn't be used. AFAIK this is totally against everything MS has said about the Framework and their intent on language differentiation. > Like, the new one I just heard that the Framework is the That's NOT WHAT I HAVE BEEN SAYING!!!> end-all-and-be-all and if it's not in it, then it shouldn't be used. For the last 10 messages or so, I have started out by trying to remind you of what I have said as I have continued to read what your interpretation of what I said was. Please don't add/remove anything to my comments. The thread is about ToString vs. CStr(). My opinion is that ToString should be used because, in my experience, Nothing values need to be separated from String values. That's my point, period - - end of story... no more ... no less. You've managed to bring Namespaces, Imports statements, the VisualBaisc objects, the differences between VB.NET and C#, building custom methods and more into this. It is MY OPINION and I have explained why I have it as well as acknowledging that others may disagree. I have never ONCE said or implied that "If it ain't in the Framework, it shouldn't be used." But that is what you repeat (as if I said it). For someone that seems to be rather intelligent, you are having a hard time sticking to the topic, without embellishing. I have never once said or implied that the native language elements of VB.NET aren't usefull or that I don't use *any* of them. I have never once indicated that encapsulation is wrong or bad...only that the type of encapsulation that CStr() offeers is not useful to me in most of the situations I encounter. It's nice that my VCR has 275+ functions encapsulated in it, but if I don't ever use most of them or don't find some of those functions usefull, I'd rather do a little more work (If statements) and get exactly what I want than to just blindly take the funcationality offered. I have also told you why I teach what I do and you've called that into question as well by indicating that the MS engineers must be wrong or not VB.NET savvy. You have no idea who these people are, nor what their credentials are. Your comments about them are purlely speculative on your part (and plain wrong as a matter of fact). In my opinion, you've done nothing but call me stupid and a liar. Oh sure, you haven't said it directly, but your comments couldn't be interpreted otherwise (and you know it). I'd hate to get into a religious, philisophical or political debate with you since you leave no room for any other viewpoint other than your own. Anyway, good luck to you. I wish you much success and hope you only meet folks who think like you do in your future. -Scott Your original post:
"you should view *all* of the old "data-type" specific functions as legacy functions and no longer use them. Instead, use the more object-oriented methods of a type." I asked *why*? Why are they legacy? Show me some proof. "CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or ..ToString" I stated CStr, CBool, etc are simply wrappers around CType. A handy *encapsulation* of CType(object, String) if not more than that. "*All* date/time functions would be replaced with methods and properties of the Date class. All string functions would be replaced with methods and properties of the String class." I ask "why?" If the VB functions provide GREATER functionality and/or better code conciseness, why not use them when it makes sense? I'm not making a case to SOLELY use them.... just don't IGNORE them. They are what make VB "VB." Then you go on in a different post about the VB keywords turning blue because they're not framework "object methods." Cor and I tried to prove the fallacy in that notion. I have stayed on topic. You just haven't been able to prove your assertion. That's not my fault. > ToString scenario. And if you want to avoid the empty string possibility Ever heard of encapsulation? If your code is littered with Is Nothing checks > of CStr(), you are going to need an IF statement to check the string, just > as you would need to check the string for Nothing using ToString, so > there's no code savings that others have indicated there would be. all over the place just to process a string you've missed the point of modern procedural programming. > That's all I've been trying to say...CStr() can get you into trouble in Name one situation.> certain situations. And when it does, it can be difficult to troubleshoot > where the problem is due to the *valid*, but empty string floating around > in memory. In almost all situations you'd usually want to treat a Nothing string as Empty. Caring whether it's actually Nothing is the exception and not something to base an entire coding practice on when it doesn't warrant it. Again, this is one area (among many) that sets VB apart from its more stripped down .NET sibling languages. > As for the additional behavior of CStr() being well known, I highly Considering CStr and its older Str cousin have been around since B.A.S.I.C. > disagree. This whole thread (and countless others) started off with the > OP confused over the difference between CStr() and .ToString. I'd chalk it up to just not understanding what VB as a high-level coding language is versus the framework its latest incarnation rides on. > Considering CStr and its older Str cousin have been around since It's obvious that you are just not willing to entertain any point of view > B.A.S.I.C. I'd chalk it up to just not understanding what VB as a > high-level coding language is versus the framework its latest incarnation > rides on. that is different than yours and that anyone who disagrees is short-sighted, ignorant and stupid. I feel that using the object oriented approach makes my code more scalable and consistent with an all-purpose approach. I also believe that people who have something to say that doesn't jive with my approach shouldn't be insulted for expanding their minds. "Scott M." <s-mar@nospam.nospam> wrote in message I think I've given examples and fully explained why I *think* you're wrong. news:uOBS5ciNGHA.420@tk2msftngp13.phx.gbl... > It's obvious that you are just not willing to entertain any point of view > that is different than yours and that anyone who disagrees is > short-sighted, ignorant and stupid. I feel that using the object oriented > approach makes my code more scalable and consistent with an all-purpose > approach. I also believe that people who have something to say that > doesn't jive with my approach shouldn't be insulted for expanding their > minds. You've offered no evidence or really explained why your suppositions are correct other than you consider VB's keywords to be "legacy." If you really believe that, then you have shown that you haven't really read
my posts. I've said over and over that if you want to treat Nothing differently than and empty string that CStr() is not a good idea. I've also indicated *why* I call CStr() and its friends legacy functions. You just haven't bothered to read what I've written. Show quoteHide quote "CMM" <cmm@nospam.com> wrote in message news:%23pDXVhiNGHA.1676@TK2MSFTNGP09.phx.gbl... > "Scott M." <s-mar@nospam.nospam> wrote in message > news:uOBS5ciNGHA.420@tk2msftngp13.phx.gbl... >> It's obvious that you are just not willing to entertain any point of view >> that is different than yours and that anyone who disagrees is >> short-sighted, ignorant and stupid. I feel that using the object >> oriented approach makes my code more scalable and consistent with an >> all-purpose approach. I also believe that people who have something to >> say that doesn't jive with my approach shouldn't be insulted for >> expanding their minds. > > I think I've given examples and fully explained why I *think* you're > wrong. You've offered no evidence or really explained why your > suppositions are correct other than you consider VB's keywords to be > "legacy." > > -- > -C. Moya > www.cmoya.com > Maybe I missed it... why are they "legacy?" Where did Microsoft state this?
Is the lowercase "string" alias for System.String in C# legacy too? Legacy to what? C# was a brand new language. You need to prove this. I say that it's not legacy... it's what makes VB "VB" and those functions and keywords Left/Right/CStr/ etc etc are in no danger of EVER being deprecated. Why? ..... well consider this: If Not s Is Nothing Then If s.Length >= 10 Then s2 = s.Substring(10) End If End If will NEVER beat: s2 = Left(s, 10)
Show quote
Hide quote
"CMM" <cmm@nospam.com> schrieb: ACK.>> That's all I've been trying to say...CStr() can get you into trouble in >> certain situations. And when it does, it can be difficult to >> troubleshoot where the problem is due to the *valid*, but empty string >> floating around in memory. > > Name one situation. > > In almost all situations you'd usually want to treat a Nothing string as > Empty. Caring whether it's actually Nothing is the exception and not > something to base an entire coding practice on when it doesn't warrant it. > > Again, this is one area (among many) that sets VB apart from its more > stripped down .NET sibling languages. >> As for the additional behavior of CStr() being well known, I highly ACK. For me the .NET Framework is the /basis/ different (high-level) >> disagree. This whole thread (and countless others) started off with the >> OP confused over the difference between CStr() and .ToString. > > Considering CStr and its older Str cousin have been around since > B.A.S.I.C. I'd chalk it up to just not understanding what VB as a > high-level coding language is versus the framework its latest incarnation > rides on. languages and (high-level) libraries can be built upon. VB.NET's function library being based on the .NET Framework I consider an implementation detail. BASIC's set of functions is basically technology-independent, which means that these functions can be easily migrated to another underlying technology. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> Give that man a Kewpie doll!
Show quoteHide quote "Bob Lehmann" <nospam@dontbotherme.zzz> wrote in message news:epp0n5NNGHA.3856@TK2MSFTNGP12.phx.gbl... >>> You can't use the OO methods on a string that is "Nothing" > > Why would you want to? > > Oh, I get it, you're too lazy to check the data before performing an > operation it. Isn't checking your data a 100 level concept? > > I'm guessing that On Error Resume Next is one of your friends too. > > Bob Lehmann > > "CMM" <cmm@nospam.com> wrote in message > news:%23h%23gzeNNGHA.1676@TK2MSFTNGP09.phx.gbl... >> I don't think that's true at all. First off, CStr,CBool, Etc. are all >> just >> easier-to-read specialized wrappers around CType..... which in and of > itself >> is a special "VB" construct. The true "non-VB" casting operator is >> DirectCast(...). >> >> Contrary to what Scott M says you're SUPPOSED to use them. What's the > point >> of using VB if you're not going to use its special methods that make your >> life easier? This is straight from the VB documentation: >> >> "As a rule, you should use the Visual Basic type conversion functions in >> preference to the .NET Framework methods such as ToString(), either on >> the >> Convert class or on an individual type structure or class. The Visual > Basic >> functions are designed for optimal interaction with Visual Basic code, >> and >> they also make your source code shorter and easier to read. In addition, > the >> .NET Framework conversion methods do not always produce the same results > as >> the Visual Basic functions, for example when converting Boolean to > Integer. >> For more information, see Troubleshooting Data Types." >> >> In addition, although I'm a guy who always initializes strings and >> objects >> as soon as possible rather than have them sit around until my algorithm > uses >> them- so I don't really care about the following- but, there's an > advantage >> to using VB's functions: they interpret "Nothing." You can't use the OO >> methods on a string that is "Nothing" (s.ToUpper for instance won't >> work). >> >> -- >> -C. Moya >> www.cmoya.com >> "Scott M." <s-mar@nospam.nospam> wrote in message >> news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... >> > IMHO (and this has been debated for quite some time now), you should > view >> > all of the old "data-type" specific functions as legacy functions and >> > no >> > longer use them. Instead, use the more object-oriented methods of a > type. >> > >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or >> > .ToString >> > All date/time functions would be replaced with methods and properties >> > of >> > the Date class >> > All string functions would be replaced with methods and properties of > the >> > String class. >> > >> > et all. >> > >> > >> > "Sean" <S***@discussions.microsoft.com> wrote in message >> > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... >> >> Book I am reading says that Cstr() is best method for efficency and >> >> safety >> >> however it doesnt compare that method of the .ToString() method. >> >> >> >> Which is best. >> >> >> >> Thanks >> >> >> >> >> > >> > >> >> > > "Bob Lehmann" <nospam@dontbotherme.zzz> schrieb: Why type 'If s IsNot Nothing AndAlso s.Length > 0 Then' if you could shorten >>> You can't use the OO methods on a string that is "Nothing" > > Why would you want to? > > Oh, I get it, you're too lazy to check the data before performing an > operation it. Isn't checking your data a 100 level concept? it to 'If Len(s) > 0 Then'? The same applies to 'ToString' vs. 'CStr': Why type \\\ If o Is Nothing Then s = "" Else s = o.ToString() End If /// if you could archieve the same by using \\\ s = CStr(o) /// ? -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> Same answer as when you asked the same question earilier in the thread.
Show quoteHide quote "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:%23NRyexVNGHA.3788@TK2MSFTNGP09.phx.gbl... > "Bob Lehmann" <nospam@dontbotherme.zzz> schrieb: >>>> You can't use the OO methods on a string that is "Nothing" >> >> Why would you want to? >> >> Oh, I get it, you're too lazy to check the data before performing an >> operation it. Isn't checking your data a 100 level concept? > > Why type 'If s IsNot Nothing AndAlso s.Length > 0 Then' if you could > shorten it to 'If Len(s) > 0 Then'? The same applies to 'ToString' vs. > 'CStr': Why type > > \\\ > If o Is Nothing Then > s = "" > Else > s = o.ToString() > End If > /// > > if you could archieve the same by using > > \\\ > s = CStr(o) > /// > > ? > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/> Would you make the same argument for CInt?
Say you wanted to exclude unanswered questions on a survey where you will average a 0 to 4 rating. 0 <> Nothing. Bob Lehmann Show quoteHide quote "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:%23NRyexVNGHA.3788@TK2MSFTNGP09.phx.gbl... > "Bob Lehmann" <nospam@dontbotherme.zzz> schrieb: > >>> You can't use the OO methods on a string that is "Nothing" > > > > Why would you want to? > > > > Oh, I get it, you're too lazy to check the data before performing an > > operation it. Isn't checking your data a 100 level concept? > > Why type 'If s IsNot Nothing AndAlso s.Length > 0 Then' if you could shorten > it to 'If Len(s) > 0 Then'? The same applies to 'ToString' vs. 'CStr': Why > type > > \\\ > If o Is Nothing Then > s = "" > Else > s = o.ToString() > End If > /// > > if you could archieve the same by using > > \\\ > s = CStr(o) > /// > > ? > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/> > > Contrary to what Scott M says you're SUPPOSED to use them. What's the You should really relax and read what was posted. If you were supposed to > point of using VB if you're not going to use its special methods that make > your life easier? use the legacy conversion functions and not the .NET ToString and CType, then why would MS add them in the first place. My post started with IMHO and that much has been debated about this before. Your opinion is fine, but it is just that. Wrappers have their own downside, which tend to be more CPU cycles. well .........
option 1 dim x as string ----- some stuff here that might or might not fill the string if not x is nothing then if x.length>0 then ---- do your stuff end if end if option 2 dim x as string = "" ----- some stuff here that might or might not fill the string if x.length>0 then ---- do your stuff end if option 3 dim x as string ----- some stuff here that might or might not fill the string if len(x)>0 then ---- do your stuff end if Well In My Homble Opinion it all depends on a few factors what should favor you 1. your personal coding style 2. design of your app ( if constructs like this happen a lot you might save some typing with option 2 or 3 ) 3. portability need to other .Net languages I believe that option 1 and 3 are the same , although it is written different option 2 is the practical guideline for VB and C# and is probably the fastest and time sparing ( prevents RSI the most :-) ) regards Michel Posseth [MCP] Show quoteHide quote "Scott M." <s-mar@nospam.nospam> schreef in bericht news:umV7TrRNGHA.2696@TK2MSFTNGP14.phx.gbl... >> Contrary to what Scott M says you're SUPPOSED to use them. What's the >> point of using VB if you're not going to use its special methods that >> make your life easier? > > You should really relax and read what was posted. If you were supposed to > use the legacy conversion functions and not the .NET ToString and CType, > then why would MS add them in the first place. > > My post started with IMHO and that much has been debated about this > before. > > Your opinion is fine, but it is just that. Wrappers have their own > downside, which tend to be more CPU cycles. > "CMM" <cmm@nospam.com> schrieb: ACK. While it doesn't matter if you use 'C<Type>' or 'CType(..., <Type>)', >I don't think that's true at all. First off, CStr,CBool, Etc. are all just >easier-to-read specialized wrappers around CType..... which in and of >itself is a special "VB" construct. I strongly recommend to use them instead of 'Convert.To*'. > The true "non-VB" casting operator is DirectCast(...). .... which doesn't mean that 'DirectCast' should not be used. Personally I prefer 'CType' for value types (type conversions) and 'DirectCast' for type casts (reference types). However, some other people prefer to use 'CType' instead of 'DirectCast'. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> To add to this, you can't use DirectCast on anything but Reference Types
anyway, so CType will need to be used for all numeric casting anyway. Show quoteHide quote "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:%23wIdkvVNGHA.428@tk2msftngp13.phx.gbl... > "CMM" <cmm@nospam.com> schrieb: >>I don't think that's true at all. First off, CStr,CBool, Etc. are all just >>easier-to-read specialized wrappers around CType..... which in and of >>itself is a special "VB" construct. > > ACK. While it doesn't matter if you use 'C<Type>' or 'CType(..., > <Type>)', I strongly recommend to use them instead of 'Convert.To*'. > >> The true "non-VB" casting operator is DirectCast(...). > > ... which doesn't mean that 'DirectCast' should not be used. Personally I > prefer 'CType' for value types (type conversions) and 'DirectCast' for > type casts (reference types). However, some other people prefer to use > 'CType' instead of 'DirectCast'. > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/> Thanks CMM, what you wrote is what I thought was true and I was looking for a
comfirmation. As far as Scott goes I was refering to a "method" using the meaning of the word "a way to". For my purposes it couldnt matter less if its a function or a method. Show quoteHide quote "CMM" wrote: > I don't think that's true at all. First off, CStr,CBool, Etc. are all just > easier-to-read specialized wrappers around CType..... which in and of itself > is a special "VB" construct. The true "non-VB" casting operator is > DirectCast(...). > > Contrary to what Scott M says you're SUPPOSED to use them. What's the point > of using VB if you're not going to use its special methods that make your > life easier? This is straight from the VB documentation: > > "As a rule, you should use the Visual Basic type conversion functions in > preference to the .NET Framework methods such as ToString(), either on the > Convert class or on an individual type structure or class. The Visual Basic > functions are designed for optimal interaction with Visual Basic code, and > they also make your source code shorter and easier to read. In addition, the > ..NET Framework conversion methods do not always produce the same results as > the Visual Basic functions, for example when converting Boolean to Integer. > For more information, see Troubleshooting Data Types." > > In addition, although I'm a guy who always initializes strings and objects > as soon as possible rather than have them sit around until my algorithm uses > them- so I don't really care about the following- but, there's an advantage > to using VB's functions: they interpret "Nothing." You can't use the OO > methods on a string that is "Nothing" (s.ToUpper for instance won't work). > > -- > -C. Moya > www.cmoya.com > "Scott M." <s-mar@nospam.nospam> wrote in message > news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... > > IMHO (and this has been debated for quite some time now), you should view > > all of the old "data-type" specific functions as legacy functions and no > > longer use them. Instead, use the more object-oriented methods of a type. > > > > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or > > .ToString > > All date/time functions would be replaced with methods and properties of > > the Date class > > All string functions would be replaced with methods and properties of the > > String class. > > > > et all. > > > > > > "Sean" <S***@discussions.microsoft.com> wrote in message > > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... > >> Book I am reading says that Cstr() is best method for efficency and > >> safety > >> however it doesnt compare that method of the .ToString() method. > >> > >> Which is best. > >> > >> Thanks > >> > >> > > > > > > > Then you should absolutely go with your preference, which is what I said in
the first place. I merely indicated what my preference was and why. Good luck! Show quoteHide quote "Sean" <S***@discussions.microsoft.com> wrote in message news:BD302974-14AE-4FAA-A3B8-1F299997BBFF@microsoft.com... > Thanks CMM, what you wrote is what I thought was true and I was looking > for a > comfirmation. > > As far as Scott goes I was refering to a "method" using the meaning of the > word "a way to". For my purposes it couldnt matter less if its a function > or > a method. > > > "CMM" wrote: > >> I don't think that's true at all. First off, CStr,CBool, Etc. are all >> just >> easier-to-read specialized wrappers around CType..... which in and of >> itself >> is a special "VB" construct. The true "non-VB" casting operator is >> DirectCast(...). >> >> Contrary to what Scott M says you're SUPPOSED to use them. What's the >> point >> of using VB if you're not going to use its special methods that make your >> life easier? This is straight from the VB documentation: >> >> "As a rule, you should use the Visual Basic type conversion functions in >> preference to the .NET Framework methods such as ToString(), either on >> the >> Convert class or on an individual type structure or class. The Visual >> Basic >> functions are designed for optimal interaction with Visual Basic code, >> and >> they also make your source code shorter and easier to read. In addition, >> the >> ..NET Framework conversion methods do not always produce the same results >> as >> the Visual Basic functions, for example when converting Boolean to >> Integer. >> For more information, see Troubleshooting Data Types." >> >> In addition, although I'm a guy who always initializes strings and >> objects >> as soon as possible rather than have them sit around until my algorithm >> uses >> them- so I don't really care about the following- but, there's an >> advantage >> to using VB's functions: they interpret "Nothing." You can't use the OO >> methods on a string that is "Nothing" (s.ToUpper for instance won't >> work). >> >> -- >> -C. Moya >> www.cmoya.com >> "Scott M." <s-mar@nospam.nospam> wrote in message >> news:O7e3xHLNGHA.2036@TK2MSFTNGP14.phx.gbl... >> > IMHO (and this has been debated for quite some time now), you should >> > view >> > all of the old "data-type" specific functions as legacy functions and >> > no >> > longer use them. Instead, use the more object-oriented methods of a >> > type. >> > >> > CStr, CBool, CDbl, CInt, etc. would all be replaced with CType or >> > .ToString >> > All date/time functions would be replaced with methods and properties >> > of >> > the Date class >> > All string functions would be replaced with methods and properties of >> > the >> > String class. >> > >> > et all. >> > >> > >> > "Sean" <S***@discussions.microsoft.com> wrote in message >> > news:68FBFD12-1AF2-4F12-821F-2CC4E6F8E957@microsoft.com... >> >> Book I am reading says that Cstr() is best method for efficency and >> >> safety >> >> however it doesnt compare that method of the .ToString() method. >> >> >> >> Which is best. >> >> >> >> Thanks >> >> >> >> >> > >> > >> >> >> 
Other interesting topics
|
|||||||||||||||||||||||
