Re: CStr() vs. .ToString()

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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

"Cor Ligthert [MVP]" <notmyfirstname@xxxxxxxxx> wrote in message
news:%23qxx%233fNGHA.3732@xxxxxxxxxxxxxxxxxxxxxxx
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




.

Relevant Pages