vb to vb.net functions

[Mike D]

I am used to using vb function like replace, inst, cstr etc. What is the
best way to find vb.net equivalents or does it matter if I continue to use
the old functions?

Mike

[Cor Ligthert]

Mike,

I am used to using vb function like replace, inst, cstr etc. What is the
best way to find vb.net equivalents or does it matter if I continue to use
the old functions?

No, you can use them those are a full part of the Net framework. With some
small exceptions.

http://msdn.microsoft.com/library/de...rykeywords.asp

You can use them in C# as well by the way. The only difference is that in
VBNet this namespace is default set.

I hope this helps,

Cor

[Mike D]

Thanks for the response. I'm glad to hear I can continue using the older
functions. I am trying to use some of the newer .net ways too.

Thanks again
Mike


"Cor Ligthert" wrote:

Mike,

I am used to using vb function like replace, inst, cstr etc. What is the
best way to find vb.net equivalents or does it matter if I continue to use
the old functions?

No, you can use them those are a full part of the Net framework. With some
small exceptions.

http://msdn.microsoft.com/library/de...rykeywords.asp

You can use them in C# as well by the way. The only difference is that in
VBNet this namespace is default set.

I hope this helps,

Cor

[yaip]

Old functions are supported but doing things the new way is easier. Say you
want to convert something to String. Type in the variable name followed by a
period. The intellisense will kick in and show you a list of valid methods.
Just select ToString. So if the variable is a, the new way to do it would be
a.ToString

-hth

"Mike D" <Mi***@discussions.microsoft.com> wrote in message
news:0A**********************************@microsof t.com...

I am used to using vb function like replace, inst, cstr etc. What is the
best way to find vb.net equivalents or does it matter if I continue to use
the old functions?

Mike

[Jon Skeet [C# MVP]]

Mike D <Mi***@discussions.microsoft.com> wrote:

Thanks for the response. I'm glad to hear I can continue using the older
functions. I am trying to use some of the newer .net ways too.

It's a bad idea in general to use legacy VB functions from C# - other
..NET coders may well not have the faintest idea what they do. Your code
will look like "C# with a VB accent" rather than being idiomatic C#
code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Jon,

It's a bad idea in general to use legacy VB functions from C# - other
.NET coders may well not have the faintest idea what they do. Your code
will look like "C# with a VB accent" rather than being idiomatic C#
code.

Although I agree, do you see now why I always tell not to use legacy C
methods in VBNet.

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no************@planet.nl> wrote:

It's a bad idea in general to use legacy VB functions from C# - other
.NET coders may well not have the faintest idea what they do. Your code
will look like "C# with a VB accent" rather than being idiomatic C#
code.

Although I agree, do you see now why I always tell not to use legacy C
methods in VBNet.

Not really, seeing as there *aren't* any legacy C methods in VB.NET.
Can you call strcmp, malloc etc? No. At least, not without using
interop, which would indeed be silly, but is very rarely suggested.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Jon

Not really, seeing as there *aren't* any legacy C methods in VB.NET.

Beside those included in the compatible namespace aren't there than not any
legancy VB methods in VBNet either. Certainly not the ones I showed in the
VisualBasic Namespace.

Maybe some unlucky methods like IIF, however those are in C# as well.

Cor

[Mike D]

ToString is easy but How do you replace the Mid function Mid(str, start, end)

Mike

"yaip" wrote:

Old functions are supported but doing things the new way is easier. Say you
want to convert something to String. Type in the variable name followed by a
period. The intellisense will kick in and show you a list of valid methods.
Just select ToString. So if the variable is a, the new way to do it would be
a.ToString

-hth

"Mike D" <Mi***@discussions.microsoft.com> wrote in message
news:0A**********************************@microsof t.com...

I am used to using vb function like replace, inst, cstr etc. What is the
best way to find vb.net equivalents or does it matter if I continue to use
the old functions?

Mike

[Jon Skeet [C# MVP]]

Cor Ligthert <no************@planet.nl> wrote:

Not really, seeing as there *aren't* any legacy C methods in VB.NET.
Beside those included in the compatible namespace aren't there than
not any legancy VB methods in VBNet either. Certainly not the ones I
showed in the VisualBasic Namespace.

Sorry, could you try writing that again? It doesn't quite make sense at
the moment.

Mid, StrReverse etc are definitely legacy functions. They were in VB,
and they've been included in the VB compatibility assemblies of .NET
just to provide a bit of backward compatibility with VB classic. The
same is *not* true of C/C++ - you can't just write calls to strcmp,
malloc etc as you would in C, thankfully.
Maybe some unlucky methods like IIF, however those are in C# as well.

No they aren't. There's a conditional operator, but an operator is
somewhat different to a function/method call. (The conditional operator
actually couldn't be written as a function/method call, as only the
appropriate operand is evaluated. I see this as a deficiency in IIF,
frankly.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Jon,

Mid, StrReverse etc are definitely legacy functions. They were in VB,
and they've been included in the VB compatibility assemblies of .NET
just to provide a bit of backward compatibility with VB classic.

This is not true and by writing this, you give a wrong idea about dotNet
functions.The Mid is not in the compatibly assemblies, it is a full method
of Net. The StrReverse is according as I wrote not a Net method.

I find it always strange that you are able to show in these newsgroups a
kind of negative opinions about VBNet methods, while we see that only from
you about C# when that is opposite to Java. It gives for me the opinion that
your knowledge of those three languages in not equal and therefore your
opinion about VBNet is only from a kind of hearing from.

Just my thought,

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no************@planet.nl> wrote:

Mid, StrReverse etc are definitely legacy functions. They were in VB,
and they've been included in the VB compatibility assemblies of .NET
just to provide a bit of backward compatibility with VB classic.

This is not true and by writing this, you give a wrong idea about dotNet
functions.The Mid is not in the compatibly assemblies, it is a full method
of Net. The StrReverse is according as I wrote not a Net method.
It's in the Microsoft.VisualBasic assembly - in other words, an
assembly which is only there to support legacy VB stuff. Put it this
way: if VB didn't use it, do you for one moment think that Mid would
exist? I don't - it's there purely for VB.NET, nothing else (even
though other languages *can* use it). To me, that makes it a legacy
function.

If it were intended for general use (e.g. from C# code), I would expect
it to appear in MSDN when I was using the C# filter - but it doesn't.

By the way, StrReverse is implemented in the same class as Mid, so I
don't know why you'd count one as not being a .NET method but the other
being okay.
I find it always strange that you are able to show in these newsgroups a
kind of negative opinions about VBNet methods, while we see that only from
you about C# when that is opposite to Java.
Nope, I'm quite happy to be critical about C# if you like, and have
commented in that way in the past. Fancy a list of things I'd like
changed?

Yes, I prefer C# to VB.NET for various reasons - including the fact
that it's a much smaller language, without including things which
should be done in a library as part of the language itself. I see no
reason to be ashamed of that preference.
It gives for me the opinion that your knowledge of those three
languages in not equal and therefore your opinion about VBNet is only
from a kind of hearing from.

I certainly know less about VB.NET than about C#, but I know enough to
say that using Mid is a way to make your code more obscure to .NET
programmers who don't know VB. It's not the idiomatic .NET way of
taking a substring.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Jon Skeet [C# MVP]"

It's in the Microsoft.VisualBasic assembly - in other words, an
assembly which is only there to support legacy VB stuff. Put it this
way: if VB didn't use it, do you for one moment think that Mid would
exist? I don't - it's there purely for VB.NET, nothing else (even
though other languages *can* use it). To me, that makes it a legacy
function.
When you make an application which is named "Jon".
And you have a main namespace that you call System.Jon
And a namespace Superior.ForMe

And you use them both those namespace in your application "Jon".
Is than the Superior namespace a part of "Jon" or is it only the System
namespace?

If it were intended for general use (e.g. from C# code), I would expect
it to appear in MSDN when I was using the C# filter - but it doesn't.

Why if you want you can as I showed in my sample use the Superior.Namespace
or any other namespace that fits you. Otherwise there was no reason to call
that standard one the "System.Net" one. That name could be ommited.
By the way, StrReverse is implemented in the same class as Mid, so I
don't know why you'd count one as not being a .NET method but the other
being okay.

You are right, however I use seldom the Microsoft.VisualBasic namespace
(only for the convert). Which does not mean that other people find a lot of
methods from it superior above the standard System.Net namespace.
Yes, I prefer C# to VB.NET for various reasons - including the fact
that it's a much smaller language, without including things which
should be done in a library as part of the language itself. I see no
reason to be ashamed of that preference.

For my you would not have to be ashamed of your preference. However, I see
in your messages seldom a sentence like "In my opinion" when you are talking
about something that is not in that preference. It is than stated as if it
are facts. By instance this legacy, that is in my opinon not an Official
Microsoft statement.
I certainly know less about VB.NET than about C#, but I know enough to
say that using Mid is a way to make your code more obscure to .NET
programmers who don't know VB. It's not the idiomatic .NET way of
taking a substring.

As I have often said before, I never use the Mid or those commands, because
I do not use commands which have a One as starting indexer. However as far
as I know are only C derived languages using the "substring", so that
obvious it is not that everybody understand that.

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no************@planet.nl> wrote:

Jon Skeet [C# MVP]"

It's in the Microsoft.VisualBasic assembly - in other words, an
assembly which is only there to support legacy VB stuff. Put it this
way: if VB didn't use it, do you for one moment think that Mid would
exist? I don't - it's there purely for VB.NET, nothing else (even
though other languages *can* use it). To me, that makes it a legacy
function.

When you make an application which is named "Jon".
And you have a main namespace that you call System.Jon
And a namespace Superior.ForMe

And you use them both those namespace in your application "Jon".
Is than the Superior namespace a part of "Jon" or is it only the System
namespace?

Eh? Sorry, I really don't see what you're getting at. (Of course,
creating my own namespace within System would be a very, very bad idea
to start with, IMO.)

If it were intended for general use (e.g. from C# code), I would expect
it to appear in MSDN when I was using the C# filter - but it doesn't.

Why if you want you can as I showed in my sample use the Superior.Namespace
or any other namespace that fits you. Otherwise there was no reason to call
that standard one the "System.Net" one. That name could be ommited.

I don't see where MSDN comes into your analogy at all. Any namespace
which should be considered as being good practice to be used by all
languages should be visible when I look at MSDN using the Visual C# (or
any other) filter, shouldn't it?

By the way, StrReverse is implemented in the same class as Mid, so I
don't know why you'd count one as not being a .NET method but the other
being okay.

You are right, however I use seldom the Microsoft.VisualBasic namespace
(only for the convert). Which does not mean that other people find a lot of
methods from it superior above the standard System.Net namespace.

That doesn't mean it's good practice to use them though. If they were
considered important enough to be in the .NET framework "proper", they
wouldn't be in a namespace which specifically refers to VB, would they?

Yes, I prefer C# to VB.NET for various reasons - including the fact
that it's a much smaller language, without including things which
should be done in a library as part of the language itself. I see no
reason to be ashamed of that preference.

For my you would not have to be ashamed of your preference. However, I see
in your messages seldom a sentence like "In my opinion" when you are talking
about something that is not in that preference. It is than stated as if it
are facts. By instance this legacy, that is in my opinon not an Official
Microsoft statement.

I couldn't possibly make an official Microsoft statement. However, I
think it's not unreasonable to infer from the fact that MS chose to
include things like Mid and StrReverse in a namespace specifically
named after VB that they had VB users in mind, not C# users.

Do *you* always write "in my opinion" when you're doing something other
than stating absolute fact, by the way? I doubt it. Do you want me to
find examples where you've stated an opinion without specifically
labelling it as such? If you want me to label every single opinion as
being an opinion, you should do the same yourself.

I certainly know less about VB.NET than about C#, but I know enough to
say that using Mid is a way to make your code more obscure to .NET
programmers who don't know VB. It's not the idiomatic .NET way of
taking a substring.

As I have often said before, I never use the Mid or those commands, because
I do not use commands which have a One as starting indexer. However as far
as I know are only C derived languages using the "substring", so that
obvious it is not that everybody understand that.

Um, substring isn't a C function in the first place, so it can't be a
legacy C function.

However, the terminology "substring" to mean a part of a string is very
common in computer science, outside C/C++ languages. Try searching for
substring and various other languages (eg Perl, Ruby, Smalltalk,
Python) and you'll find plenty of descriptions which include the word
for precisely that reason. I don't think you'll find many using "Mid"
in the description...

Using String.Substring is the standard, idiomatic way of taking part of
a string. It's not a legacy function at all. Now, do you have any
actual examples of "legacy C methods"?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Jon,

And you use them both those namespace in your application "Jon".
Is than the Superior namespace a part of "Jon" or is it only the System
namespace?

Eh? Sorry, I really don't see what you're getting at. (Of course,
creating my own namespace within System would be a very, very bad idea
to start with, IMO.)
I changed those names. I started with Jon.Standard and Whatever.Superior,
now it becomes less clear. However let this go, I think the following the
text is more important for this discussion, where I don't quote your text
because it goes about what you wrote, not the words.

I agree with you, it *could* have been in my opinion as well better when
Microsoft had included the Microsoft Namespace inside .Net. However,
sometimes there are less logical decissions to make, to run with the hare
and hold with the hounds.

I don't know this, however there was as well of course the situation that C#
had to become accepted as a proffesional language. What could have mean,
that some C++ programmers would have never accepted that, when there was
VBNet syntax inside that.

This above is just guessing from me and there can be a lot of reassons. The
effect is that for people who do not know better, it looks like that it is
outside, while it is in fact (as I see it) inside, however has another name
(You cannot buy VSNET withouth it, and it is as well in the Net SDK).

The only thing you have to do to use it in other languages, is set a
reference and an "using", the same as with most namespaces. I did not do a
check as you did with the Idispose, however I think that less than 10% is
standard referenced and/or a standard "using" in C#. While in VBNet is just
the 'reference" and the "using (imports)" standard set in the project
properties.

I find it even strange that people writing C# languages are using in all
kind of namespaces, however avoid as hell the Microsoft.VisualBasic
namespace. While by instance some datetime methods in that namespace are
very strong. I see objective no reasons, why not to use them (the only
reason is that is looks strange for C# people). They act like all C# written
methods could do. (I agree to avoid all First starting indexer methods or
whatever in C#, as I forever write to you, do I that myself in VBNet as
well. However, in my idea are people free to decide that themselves in
VBNet).
I couldn't possibly make an official Microsoft statement. However, I
think it's not unreasonable to infer from the fact that MS chose to
include things like Mid and StrReverse in a namespace specifically
named after VB that they had VB users in mind, not C# users.
The mainpoint of my message to you was the word "legacy" that you often use
as if it is an official statement from Microsoft. Maybe do you not agree
with what I wrote above, you would in my opinion at least have to agree with
me, that there can be other reasons than that you think that Microsoft had.

Cor


"Jon Skeet [C# MVP]" <sk***@pobox.com> schreef in bericht
news:MP***********************@msnews.microsoft.co m... Cor Ligthert <no************@planet.nl> wrote:

Jon Skeet [C# MVP]"

> It's in the Microsoft.VisualBasic assembly - in other words, an
> assembly which is only there to support legacy VB stuff. Put it this
> way: if VB didn't use it, do you for one moment think that Mid would
> exist? I don't - it's there purely for VB.NET, nothing else (even
> though other languages *can* use it). To me, that makes it a legacy
> function.

When you make an application which is named "Jon".
And you have a main namespace that you call System.Jon
And a namespace Superior.ForMe

And you use them both those namespace in your application "Jon".
Is than the Superior namespace a part of "Jon" or is it only the System
namespace?

Eh? Sorry, I really don't see what you're getting at. (Of course,
creating my own namespace within System would be a very, very bad idea
to start with, IMO.)
> If it were intended for general use (e.g. from C# code), I would expect
> it to appear in MSDN when I was using the C# filter - but it doesn't.

Why if you want you can as I showed in my sample use the
Superior.Namespace
or any other namespace that fits you. Otherwise there was no reason to
call
that standard one the "System.Net" one. That name could be ommited.

I don't see where MSDN comes into your analogy at all. Any namespace
which should be considered as being good practice to be used by all
languages should be visible when I look at MSDN using the Visual C# (or
any other) filter, shouldn't it?

> By the way, StrReverse is implemented in the same class as Mid, so I
> don't know why you'd count one as not being a .NET method but the other
> being okay.

You are right, however I use seldom the Microsoft.VisualBasic namespace
(only for the convert). Which does not mean that other people find a lot
of
methods from it superior above the standard System.Net namespace.

That doesn't mean it's good practice to use them though. If they were
considered important enough to be in the .NET framework "proper", they
wouldn't be in a namespace which specifically refers to VB, would they?

> Yes, I prefer C# to VB.NET for various reasons - including the fact
> that it's a much smaller language, without including things which
> should be done in a library as part of the language itself. I see no
> reason to be ashamed of that preference.

For my you would not have to be ashamed of your preference. However, I
see
in your messages seldom a sentence like "In my opinion" when you are
talking
about something that is not in that preference. It is than stated as if
it
are facts. By instance this legacy, that is in my opinon not an Official
Microsoft statement.

I couldn't possibly make an official Microsoft statement. However, I
think it's not unreasonable to infer from the fact that MS chose to
include things like Mid and StrReverse in a namespace specifically
named after VB that they had VB users in mind, not C# users.

Do *you* always write "in my opinion" when you're doing something other
than stating absolute fact, by the way? I doubt it. Do you want me to
find examples where you've stated an opinion without specifically
labelling it as such? If you want me to label every single opinion as
being an opinion, you should do the same yourself.

> I certainly know less about VB.NET than about C#, but I know enough to
> say that using Mid is a way to make your code more obscure to .NET
> programmers who don't know VB. It's not the idiomatic .NET way of
> taking a substring.

As I have often said before, I never use the Mid or those commands,
because
I do not use commands which have a One as starting indexer. However as
far
as I know are only C derived languages using the "substring", so that
obvious it is not that everybody understand that.

Um, substring isn't a C function in the first place, so it can't be a
legacy C function.

However, the terminology "substring" to mean a part of a string is very
common in computer science, outside C/C++ languages. Try searching for
substring and various other languages (eg Perl, Ruby, Smalltalk,
Python) and you'll find plenty of descriptions which include the word
for precisely that reason. I don't think you'll find many using "Mid"
in the description...

Using String.Substring is the standard, idiomatic way of taking part of
a string. It's not a legacy function at all. Now, do you have any
actual examples of "legacy C methods"?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Cor Ligthert <no************@planet.nl> wrote:

<snip>

The only thing you have to do to use it in other languages, is set a
reference and an "using", the same as with most namespaces. I did not do a
check as you did with the Idispose, however I think that less than 10% is
standard referenced and/or a standard "using" in C#. While in VBNet is just
the 'reference" and the "using (imports)" standard set in the project
properties.
Not sure what you mean by "standard referenced". It just depends on the
project.
I find it even strange that people writing C# languages are using in all
kind of namespaces, however avoid as hell the Microsoft.VisualBasic
namespace.
Because, as I've said, it's not the idiomatic way of using .NET.
While by instance some datetime methods in that namespace are
very strong. I see objective no reasons, why not to use them (the only
reason is that is looks strange for C# people).
That is reason enough, in my view. Readability is king, IMO.

I couldn't possibly make an official Microsoft statement. However, I
think it's not unreasonable to infer from the fact that MS chose to
include things like Mid and StrReverse in a namespace specifically
named after VB that they had VB users in mind, not C# users.

The mainpoint of my message to you was the word "legacy" that you often use
as if it is an official statement from Microsoft.

I've never said it's an official statement from Microsoft, nor have I
implied as much any more than I imply any of my other statements are
official ones from Microsoft.
Maybe do you not agree with what I wrote above, you would in my
opinion at least have to agree with me, that there can be other
reasons than that you think that Microsoft had.

Yes, there could be other reasons. Until I see any evidence to the
contrary, however, I'll continue to believe the simplest explanation -
that the stuff in Microsoft.VisualBasic.dll is intended for VB.NET
users, and was never particularly envisaged as being used by C# users.
I continue to believe that none of it would be present if VB.NET didn't
exist, which to me ties it closely to VB.NET rather than being
something to be globally used.
However, to be absolutely clear:
It is *my opinion*, and my opinion only, not that necessarily of
Microsoft, or my employer, or my wife or my cats, that C# programmers
would be wise to avoid the Microsoft.VisualBasic namespace in favour of
the System.* namespaces.
I notice you still haven't provided any actual examples of legacy C
functions, by the way...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Jon,

It adds nothing to the discussion, however when you want.

I notice you still haven't provided any actual examples of legacy C
functions, by the way...

When I see *parse* in a VBNet program than I see that as a legacy C method.
With the same explanation as you did that in the previous message about VB
methods in C#. (See that from my point of view that the
Microsoft.VisualBasic is a standard part of the Net SDK).

I am sure that you don't agree with me, however that is from my point of
view when it is from VBNet. When I look to it from C# than it is for me not
a legacy function. (Before you start to discuss about the use of the parse
by VBNet in ILS and things like that, I know that, that representation
follows C rules and is therefore complete valid).

The C literals find I by the way in every way a kind of legacy. However
again my personal point of view.

For me is this not worth do discuss, because I find that everybody's is free
to have is personal opinion about this. It is has in my opinion not that
much influence on the readability or the performance of a program that it
really does bother me.

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no************@planet.nl> wrote:

It adds nothing to the discussion, however when you want.

I notice you still haven't provided any actual examples of legacy C
functions, by the way...

When I see *parse* in a VBNet program than I see that as a legacy C method.

Why? There's no C function called parse. Which C function were you
thinking of? If it had been called "atoi" or "atof" you'd have had a
point, but it's not...
With the same explanation as you did that in the previous message about VB
methods in C#. (See that from my point of view that the
Microsoft.VisualBasic is a standard part of the Net SDK).

I am sure that you don't agree with me, however that is from my point of
view when it is from VBNet. When I look to it from C# than it is for me not
a legacy function. (Before you start to discuss about the use of the parse
by VBNet in ILS and things like that, I know that, that representation
follows C rules and is therefore complete valid).
I think you probably have a different idea of what "legacy" means from
me. My view on "legacy" is "something which is required to get old
stuff to play nicely, but isn't really the way to work in the future".
In other words, it's mostly for backward compatibility reasons.

The Parse methods (along with Convert, depending on your usage) are the
standard ways of parsing. They're not legacy methods by any stretch.

If you were talking about the syntax of the "switch" statement in C#,
you'd be absolutely right - it's a shame that wasn't overhauled - but
methods such as Parse? Nope.
The C literals find I by the way in every way a kind of legacy. However
again my personal point of view.

For me is this not worth do discuss, because I find that everybody's is free
to have is personal opinion about this. It is has in my opinion not that
much influence on the readability or the performance of a program that it
really does bother me.

It certainly does have an influence on the readability of the program -
once you start using non-idiomatic ways of doing things, readability
decreases significantly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Jon,

I hope that you have read that what I wrote in my previous message about
*parse* was not about its use in C#.

Therefore I do not understand your message.

However I see people with a C++ background use consequently *parse* in
VBNet. Avoiding the in my opinion better and for the VBNet programmer better
readable solutions in VBNet. Therefore that part of your message fits
exactly what I want to say.

The last looks for me the same as using the Mid method in C#.

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no************@planet.nl> wrote:

I hope that you have read that what I wrote in my previous message about
*parse* was not about its use in C#.

Therefore I do not understand your message.
Well, the first point is that Parse isn't a C function, so I can't see
how you can think it's a "legacy C function".
However I see people with a C++ background use consequently *parse* in
VBNet.
Indeed - why shouldn't they? It's one of the idiomatic ways of parsing
when you're using the .NET framework.
Avoiding the in my opinion better and for the VBNet programmer better
readable solutions in VBNet. Therefore that part of your message fits
exactly what I want to say.
How? Why?
The last looks for me the same as using the Mid method in C#.

I don't see why. There's nothing "legacy" about Parse at all - it's a
perfectly normal method. Note that it's not in an assembly which has
anything indicating it's not for general use, or that it's aimed at a
particular language.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

"Jon Skeet [C# MVP]"

Cor

While by instance some datetime methods in that namespace are
very strong. I see objective no reasons, why not to use them (the only
reason is that is looks strange for C# people). Jon

That is reason enough, in my view. Readability is king, IMO.

Cor However I see people with a C++ background use consequently *parse* in
VBNet.

Jon Indeed - why shouldn't they? It's one of the idiomatic ways of parsing
when you're using the .NET framework.

You again make the mistake to think about the System.Net namespace as the
System Net framework. In the framework there are for VBNet (in my opinion)
better methods.

In addition, you forget as well that there are (as written by an article
from a C# adept much more good VB programmers), than that there are good C#
programmers.

I stop with this, it is again without any sense

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no************@planet.nl> wrote:

Cor

However I see people with a C++ background use consequently *parse* in
VBNet.

Jon

Indeed - why shouldn't they? It's one of the idiomatic ways of parsing
when you're using the .NET framework.

You again make the mistake to think about the System.Net namespace as the
System Net framework.

Um, Parse isn't even in the System.Net namespace, so I'm not sure where
you're coming from here.

I *do* think that the System namespace and its "child" namespaces
should be considered the bedrock of the framework. When there's a
choice of using a class from a System.* namespace and one in a non-
System namespace, I believe that using System will lead to code which
is (in the long run at the very least) more readable to more people.
In the framework there are for VBNet (in my opinion) better methods.
In what way are they better?
In addition, you forget as well that there are (as written by an article
from a C# adept much more good VB programmers), than that there are good C#
programmers.

But VB "Classic" will be used less and less over time, whereas the .NET
framework will be used more and more - so using the idiomatic .NET way
of doing things is better in the long run.

The very fact that with the C# filter turned on in MSDN you don't even
get to *see* the methods/types in Microsoft.VisualBasic is enough to
put me off, to be honest. I shouldn't have to pretend to be writing in
VB.NET in order to understand someone's C# code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Jon,

Thinking it over what you told, I assume that I now see what you mean with
"legacy".

In the way I understand it from you: "Colour" is legacy in the English
language, because there is now used "Color".

While it is for me just another way of express in characters.

Do you advice me to use not anymore those legacy words when I write
something here?

Or did I understand you wrong?

:-)

Cor