Cor Ligthert said:
Bob,
What is the advantage from this, in my idea can you than better write it
direct in C
All I'm saying is that the CLR provides virtually all the classes and
methods you need for conversions. .NET-hosted languages that have legacy
syntax for doing the same things as the CLR methods will either implement
compiler syntax sugar that substitutes CLR calls for the legacy syntax, or
they will provide a library that implements the legacy syntax / behaviors.
VB.NET does primarily the latter, but with a little bit of syntax sugar --
the namespace / library where the compatibility methods exist is always
automatically referenced without the VB.NET developer having to do anything.
In the best case, if you call the legacy VB function CInt(), it's just going
to forward it to Convert.ToInt32() anyway. Why not avoid that extra call?
In the worst case, CInt() is going to implement some legacy behavior that
might be even more expensive. For example it might take Nothing as zero,
which would involve another test or perhaps a try/catch. I don't recall
offhand -- but I remember finding that some of the legacy conversion
functions do jump through extra hoops to behave exactly like legacy VB.
I'm not passing judgment on this as good, bad or indifferent -- it's just
the way it is. I'm sure that some future version of C# will have similar
issues. The initial release of C# didn't have to cope with legacy issues
since it was a brand-new language, but over time, it will. I also assume
that COBOL.NET, S#, Eiffel.NET, etc., have similar kludges to help legacy
code run somewhat as-is.
What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java
and what ever from C derived languages have a lot of legacy C stuff. (With
what in my opinion is almost nothing wrong by the way)
I'm not referring to language characteristics or conventions that descend
from predecessor languages. I'm referring to keywords / functions /
commands that are obsoleted by the provided .NET classes and which exist
only so that code written for previous, non .NET versions of those languages
will come as close as feasible to running unchanged.
I don't think anyone seriously recommends using, for example, PRINT#
statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too.
People use them to ease the incorporation of legacy code into .NET apps, or
out of habit; I'm simply advocating that they be treated like deprecated
HTML tags, which is to say, they will probably not be supported someday and
there are arguably better ways of doing the same things.
The parallel to deprecated HTML tags also cuts the other way. <B> is
deprecated, for example, but so many people continue to use it that it
probably will continue to be supported just from sheer inertia. That
probably means it's simple and abbreviated enough that it is useful and
appealing despite the fact it's obsolete. One could argue that CInt() is
more concise than Convert.ToInt32() and maybe on that basis plus the fact
that probably most VB.NET developers started out with VB6, CInt() will
remain enshrined in the language forever. Personally though I prefer to
take the larger view that you want VB.NET to participate as an equal partner
with other .NET languages and it should play in the sandbox the same way so
that programmers can move between VB.NET and other .NET languages with a
minimum of quirky exceptions to how things are done from one language to the
next.
--Bob