CStr() vs. .ToString()

[Cor Ligthert [MVP]]

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

 

[Scott M.]

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.

 

[CMM]

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)

 

[CMM]

Where'd you get this notion that VB's functions will be deprecated at some
point?

 

[CMM]

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.

As you stated stated, you think StringUtility.CStr() would better conform to
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....

The immutable nature of the String class does not break any OO doctrine.
It simply has to do with memory management. There goes nothing.

And CStr simply has to do with encapsulation. If s.ToUpper doesn't break OO
doctrine in your book, then I don't seee how Microsoft.VisualBasic.CStr()
does.

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.

You base this opinion on what?

I call CStr(), LCase(), UCase(), Time(), Hour(), Replace(), Split() et all
legacy functions because I believe that's what they are.

You "Believe" based on what? Here's why you're wrong: Using
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
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.

C# has a "string" ALIAS for System.String (note the All lowercase). There
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.

Yes.

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

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?

You're mixing things up again. VB may be a verbose language in that it uses
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!

 

[CMM]

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.

 

[CMM]

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.

 

[Scott M.]

Your question boils down to this one: What object is CStr() a method of?

 

[Scott M.]

MS Engineers that have been working for 5 years now with the companies I do
business with.

 

[CMM]

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.

 

[CMM]

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

 

[Scott M.]

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?

 

[Scott M.]

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.

 

[Herfried K. Wagner [MVP]]

Scott,

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?

I am wondering how you come to the perception that everything bust be an
"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.

 

[Herfried K. Wagner [MVP]]

MS Engineers that have been working for 5 years now with the companies I
do business with.

Well, maybe those MS engineers are disguised C#ies. I do not see any
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).

 

[Herfried K. Wagner [MVP]]

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


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.

ACK. For me the .NET Framework is the /basis/ different (high-level)
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.

 

[Herfried K. Wagner [MVP]]

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.

There is a difference between a general recommendation and a conditional
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.

 

[YYZ]

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

 

[Herfried K. Wagner [MVP]]

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.

Programming is about religious fundamentalism and feature-evangelism. I
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.

 

[Herfried K. Wagner [MVP]]

Encapsulation doesn't have anything to do with that SafeGetString
function...right?

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.