CStr() vs. .ToString()

  • Thread starter Thread starter Guest
  • Start date Start date
CMM said:
It prefer CStr as it's compiled as an inline conversion. That's beautiful.
;-)
ACK.

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

ACK. As 'CStr' is a conversion operator it's basically as object-oriented
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.
 
I am wondering how you come to the perception that everything bust be an
"object method".
Click to expand...

I never said it should be. I said (for the umpteenth time) the I *prefer*
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.
 
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().
 
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."
 
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. :-)
 
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.
 
CMM said:
P.S. I have always liked the elegance of C's casting though. :-)
Click to expand...

I liked the 'C*' casting more than the '(<type>)<...>' casting because it
doesn't suffer from the "lots of braces" problem ('CType(x.U, Z).Y' vs.
'((Z)x.U).Y').
 
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().
Click to expand...

Ahh. That is definitely NOT how I would do it. I would put it into my
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
 
Encapsulation is not only about encapsulating things in classes. It's the
general concept of encapsulating functionality in entities, which can be
procedures or classes, for example.
Click to expand...

I'm not sure I follow this...but are you saying that you would/could
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
 
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.
 
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.
 
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.
 
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.
 
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.
 
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().
 
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.
Click to expand...

That's NOT WHAT I HAVE BEEN SAYING!!!

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
 
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.
 
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.
 
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.

--
-C. Moya
www.cmoya.com

Scott M. said:
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().
Click to expand...
 
Back
Top