getting rid of old vb6 code

[Scott M.]

This is the "can of worms" I anticipated:

You are entitled to you opinion, I'm trying to answer the OP.

Reducing the "complexity" of the code for common tasks.

IMHO it doesn't seem that complex to use an object method instead of a
function. In fact, it seems more intuitive. String objects will have
string methods, math objects will have math methods, numeric objects with
have numeric methods, data objects will have date methods AND the
intellisense will only show those methods that are applicable to that
particular object. If I use the old function approach, I open the door to
type mismatches and I have to remember the names of all those functions (no
intellisense).

Who cares? That's some ns of processing.

Ok, maybe (or apparently) you don't, but those interested in performance
might.

 

[Scott M.]

- I'm used to msgbox
- Messagebox.Show is more to type
- The overhead with Msgbox is unimportant (UI stuff; user won't notice it)

Which is why MS put the Microsoft.VisualBasic namespace into the Framework.
If you want to use it, that's fine, go ahead. But removing this namespace
does what the OP had asked for and if you look at my other response, in most
cases, using the new method calls instead of the old function calls is not
only more efficient, but more intuitive and easier because of intellisense.

 

[Armin Zingler]

Which is why MS put the Microsoft.VisualBasic namespace into the
Framework. If you want to use it, that's fine, go ahead. But
removing this namespace does what the OP had asked for and if you
look at my other response, in most cases, using the new method calls
instead of the old function calls is not only more efficient, but
more intuitive and easier because of intellisense.

I didn't read the whole thread. I only gave my personal opinion on "Why take
the extra step with the function when you can go straight to the
functionality you want with the method."

 

[Herfried K. Wagner [MVP]]

You are entitled to you opinion, I'm trying to answer the OP.


IMHO it doesn't seem that complex to use an object method instead of a
function. In fact, it seems more intuitive. String objects will have

Sure, I fully agree. I was not sure if "complexity" was the right word,
that's why I put it between quotation marks.

 

[Herfried K. Wagner [MVP]]

Which is why MS put the Microsoft.VisualBasic namespace into the Framework.
If you want to use it, that's fine, go ahead. But removing this namespace
does what the OP had asked for and if you look at my other response, in most
cases, using the new method calls instead of the old function calls is not
only more efficient, but more intuitive and easier because of intellisense.

For common tasks I don't need intellisense. I don't need intellisense
for 'MsgBox', 'Strings.Left', etc.

 

[Herfried K. Wagner [MVP]]

Which is EXACTLY what the OP said he wanted to do: "Is there any program
available that I can get to sweep through VB.Net projects and flag these
older VB functions/things ?"

Im my interpreation the OP wanted to get rid of VB6 code which has a
poor design. The methods provided in the 'Microsoft.VisualBasic'
namespace are not "old" and "out of date", they are valid part of/in
Visual Basic .NET code.

 

[Scott M.]

Im my interpreation the OP wanted to get rid of VB6 code which has a

poor design. The methods provided in the 'Microsoft.VisualBasic'
namespace are not "old" and "out of date", they are valid part of/in
Visual Basic .NET code.

In my interpretation the OP wanted to get rid of VB 6 functions (he actually
said this) AND move to a more OO way of programming in general.

The "can of worms" I've been mentioning is that IMHO the
Microsoft.VisualBasic namespace DOES represent the "old" and "out of date"
way of doing things and that they are not the OO way to handle thier
functionality.

I believe that the only reason that they are in the Framework is to provide
a "crutch" to VB 6 developers so that when they migrate to VB.NET, they will
have some old "friends" that will still work.

Because of the fact that the "old" functions have "new" method calls that
are more efficient, there is (again IMHO) no reason to continue their use.

I work with a global insurance giant that recently disabled the use of this
namespace enterprise-wide as an attempt to come closer to a more OO and .NET
approach to application development.

 

[Scott M.]

But all developers are not you.

If you need a variable (x) to take on a date value that is 6 days from
today, you would have to already know about the old VB 6.0 DateAdd function
because you will not get any intellisense after typing:

Dim x as Date
x =

You would have to know how to complete that statement: x = DateAdd("d", 6,
Date())

But with the new, more object centric approach, you would type:

Dim x as Date
x.

And as soon as you type the ".", you get intellisense where you will see the
DateAdd function and a short description of it. So, for someone who didn't
have VB 6 experience, they could still get themself to:

x.DateAdd("d",6,Date())

Again, use the "old" way if you want. They are part of the framework, but
they are generally more processing intensive and less intuitive than the new
way.

 

[Herfried K. Wagner [MVP]]

But all developers are not you.

.... and all developers are not you too.

If you need a variable (x) to take on a date value that is 6 days from
today, you would have to already know about the old VB 6.0 DateAdd function
because you will not get any intellisense after typing:

Dim x as Date
x =

You would have to know how to complete that statement: x = DateAdd("d", 6,
Date())

But with the new, more object centric approach, you would type:

Dim x as Date
x.

And as soon as you type the ".", you get intellisense where you will see the
DateAdd function and a short description of it. So, for someone who didn't
have VB 6 experience, they could still get themself to:

x.DateAdd("d",6,Date())

Again, use the "old" way if you want. They are part of the framework, but
they are generally more processing intensive and less intuitive than the new
way.

ACK, that's a big advantage, but as long as some VB.NET methods provide
a good shortcut, I will prefer them (I won't use 'DateAdd'). But even
if I would use it I don't see a problem because it's very easy to
understand and read.

 

[Herfried K. Wagner [MVP]]

In my interpretation the OP wanted to get rid of VB 6 functions (he actually
said this) AND move to a more OO way of programming in general.

The "can of worms" I've been mentioning is that IMHO the
Microsoft.VisualBasic namespace DOES represent the "old" and "out of date"
way of doing things and that they are not the OO way to handle thier
functionality.

That's IMO one of the biggest misinterpretations ever done. Code
written using the functions contained in 'Microsoft VisualBasic' won't
reduce readability and maintainability of the code. In some cases, it
will increase intuitivity. And last bug not least, using the "old"
functions won't lead to more errors in the code.

I believe that the only reason that they are in the Framework is to provide
a "crutch" to VB 6 developers so that when they migrate to VB.NET, they will
have some old "friends" that will still work.

I believe that they are in the framework to make VB.NET a good (better)
RAD tool (than C#). They will never disappear and I am glad to see that
the RAD character of VB.NET (many "shortcuts") will be extended in the
next release of VB.NET ("Whidbey", 2004).

OOP is good and it has a lot of advantages over other concepts when
talking about /components/, /interfaces/ and large applications. OOP
mainly makes writing and maintainance of large applications with a
complex architecture easier. Nevertheless, procedural approaches still
are perfect inside the implementation of classes, they are not out of
date.

Because of the fact that the "old" functions have "new" method calls that
are more efficient, there is (again IMHO) no reason to continue their use.

Who says that they are more efficient? Sometimes there isn't even a
replacement in the FCL. An interesting article on this topic can be
found here:

I work with a global insurance giant that recently disabled the use of this
namespace enterprise-wide as an attempt to come closer to a more OO and .NET
approach to application development.

I don't see any advantages...

 

[Scott M.]

That's IMO one of the biggest misinterpretations ever done.

What is? That's what the OP said he wanted:

"Is there any program available that I can get to sweep through VB.Net
projects and flag these older VB functions/things?"

Code written using the functions contained in 'Microsoft VisualBasic' won't
reduce readability and maintainability of the code.

Sure it would, to the novice programmer. If I run across: Mid(blah blah),
would I intuitively know that Mid was a string function? No. But if I see a
string object with a method after it, I know that that method must be a
string method.

In some cases, it will increase intuitivity.

Maybe, but I can't think of any. Can you?

And last bug not least, using the "old" functions won't lead to more

errors in the code.

Sure they could. Again novice programmers could use a string function on a
date, a date function on a string, a math funciton on a date, etc. This
method approach will prevent type mismatches.

use.

Who says that they are more efficient? Sometimes there isn't even a
replacement in the FCL. An interesting article on this topic can be
found here:

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha
rt/html/vbtchMicrosoftVisualBasicNETInternals.asp>

If a function has to call a method then isn't it more effecient to just call
the method directly and not have to pass data an extra time? You are right,
sometimes there isn't a replacement, and so we are not talking about ALL VB
6.0 functions.

It's also interesting in that article you posted a link to that they discuss
the Microsoft.VisualBasic.Compatibility namespace and say that "The
compatibility classes should not be used for new development."

The compatability namespace and the VisualBaisc namespace have certain
similarities.

I don't see any advantages...

Ok, we agree to disagree.

 

[chookeater]

Thanks Scott.

Always the simple answers that are the best

Removing the Namespace at least alerts me to code to avoid in future projects.

Thanks to all the others who responded as well.

Chook.

 

[Herfried K. Wagner [MVP]]

What is? That's what the OP said he wanted:

"Is there any program available that I can get to sweep through VB.Net
projects and flag these older VB functions/things?"

Do you want to flag all 'If's, 'Do's, 'With's etc. too? They are "old"
too.

Sure it would, to the novice programmer. If I run across: Mid(blah blah),
would I intuitively know that Mid was a string function? No. But if I see a
string object with a method after it, I know that that method must be a
string method.

No, absolutely not. Calling a 'String' object's method isn't more
intuitive for a "beginner" who isn't familiar with object oriented
programming. IMO it's impossible to be a good OO programmer without
having good knowledge in procedural programming, which is a basis.

Maybe, but I can't think of any. Can you?

'Strings.Left', 'Strings.Right', for example. There is no direct and
descriptive replacement available in the string class.

Sure they could. Again novice programmers could use a string function on a
date, a date function on a string, a math funciton on a date, etc. This
method approach will prevent type mismatches.

You can still pass wrong datatypes to methods of objects. I think
that's not a big problem.

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha
rt/html/vbtchMicrosoftVisualBasicNETInternals.asp>

If a function has to call a method then isn't it more effecient to just call
the method directly and not have to pass data an extra time? You are right,
sometimes there isn't a replacement, and so we are not talking about ALL VB
6.0 functions.
ACK.

It's also interesting in that article you posted a link to that they discuss
the Microsoft.VisualBasic.Compatibility namespace and say that "The
compatibility classes should not be used for new development."

I wouldn't use the /compatibility/ classes which reside in the Microsoft
Visual Basic .NET Compatibility Library, as the documentation states
that it may not be included in a future release.

The compatability namespace and the VisualBaisc namespace have certain
similarities.

Let's see it from an other point of view: Microsoft made a strict
distinction between the compatibility library and the VB.NET
class/method library.

Ok, we agree to disagree.

 

[Scott M.]

Do you want to flag all 'If's, 'Do's, 'With's etc. too? They are "old"

too.

Well now, you are just being sarcastic. I know that you know that these are
language constructs and not functions.

No, absolutely not. Calling a 'String' object's method isn't more
intuitive for a "beginner" who isn't familiar with object oriented
programming. IMO it's impossible to be a good OO programmer without
having good knowledge in procedural programming, which is a basis.

Would a beginner programmer know what the string methods are intuitively?
No. But if they type a "." next to a string object, intellisense will help
them to learn what the string methods are.

'Strings.Left', 'Strings.Right', for example. There is no direct and
descriptive replacement available in the string class.

It's true that there are no string method replacements for those, but that's
not an example of how the old Left() and Right() are more intuitive. I
still have to know of thier existance before I can use them. I wouldn't
just intuitively know that they exist.

You can still pass wrong datatypes to methods of objects. I think
that's not a big problem.

Yes, but I'm taling about using a date function when you should have been
using a string function, not passing a date when you should have passed a
string. Intelisense will help the user in either the old or new way to pass
the right data into the function/method, but with the older functions, the
programmer has to somehow now the categories of functions. With methods,
there's no possibilty of that.

 

[Herfried K. Wagner [MVP]]

Well now, you are just being sarcastic. I know that you know that these are
language constructs and not functions.

Yep -- I was a little bit sarcastic.

Would a beginner programmer know what the string methods are intuitively?
No. But if they type a "." next to a string object, intellisense will help
them to learn what the string methods are.

Not every "beginner" uses the VS.NET IDE for writing his/her source
code.

;-)

It's true that there are no string method replacements for those, but that's
not an example of how the old Left() and Right() are more intuitive. I
still have to know of thier existance before I can use them. I wouldn't
just intuitively know that they exist.

The same with the methods of the 'String' class... Without getting the
information somewhere, I don't know it.

Yes, but I'm taling about using a date function when you should have been
using a string function, not passing a date when you should have passed a
string. Intelisense will help the user in either the old or new way to pass
the right data into the function/method, but with the older functions, the
programmer has to somehow now the categories of functions. With methods,
there's no possibilty of that.

As mentioned previously, I agree with you for most cases. The methods
of the classes are better, but sometimes there doesn't exist an 1:1
equivalent and VB.NET's function is more intuitive. It would be nice if
the "missing" methods would be added to the classes contained in the
FCL, so they can be removed from the VB.NET Runtime Library.

 

[Scott M.]

No, absolutely not. Calling a 'String' object's method isn't more

Not every "beginner" uses the VS.NET IDE for writing his/her source
code.

Even more of a case for organizing old functions into object methods! Less
chaotic!

The same with the methods of the 'String' class... Without getting the
information somewhere, I don't know it.

You want the information somewhere? Type a dot "." after your object.

As mentioned previously, I agree with you for most cases. The methods
of the classes are better, but sometimes there doesn't exist an 1:1
equivalent and VB.NET's function is more intuitive. It would be nice if
the "missing" methods would be added to the classes contained in the
FCL, so they can be removed from the VB.NET Runtime Library.

And on that point we agree! Good night.

 

[Herfried K. Wagner [MVP]]

You want the information somewhere? Type a dot "." after your object.

Type 'Strings' and a ".", then...

;->

And on that point we agree! Good night.

Good night.

 

[Cor]

Hi Scott,

From who do you have this information, some own made?

By disabling the Microsoft.VisualBasic namespace, you disable many of the
old VB 6 functions and therefore you are left with the new .NET object
methods (which, as I stated earlier are usually more efficient because there
is no extra step to invoke them).

It is not true the are sometimes more efficient some time less efficient.

Why I don't know but probably because they have to carry some extra with
them.

The Find of a string is twice as fast as the Instring.

Cor

 

[Cor]

Hi Scott,

My problem with this kind of answers from you is (and this is not the first
time) that you give the OP the idea that by removing the classic VB
functions he starts writing OOP.

That is not, when he does only what you say, he is is making JavaScript
look-alike VB programs.

Because I have seen in other groups that you probably come from that
direction, it is possible that you have that misunderstanding.

This is not to flame; in opposite of that, it is just to get a better
understanding why you are always post this kind of messages.

Cor

 

[Herfried K. Wagner [MVP]]

My problem with this kind of answers from you is (and this is not the first
time) that you give the OP the idea that by removing the classic VB
functions he starts writing OOP.

Full ACK. Writing good OO code doesn't depend on using procedures or
don't using them inside the implementation. Far more important is the
application's class design, methods, good encapsulation etc. By
avioding the use of VB.NET's procedures, an application's design isn't
improved.

But I understand Scott -- he loves OOP and he loves /only/ OOP.