Is it worth while in developing VB.NET or C#.NET

[Cor Ligthert [MVP]]

Jon,

Um, yes it does. Having an instance method which acts on an instance of
a class is more OO than having a static method in a separate class to
operate on an instance of the first class.

I would be the last to deny that, however as I see how often samples are
given in C# about datalayers which are made static, than I think that your
comment is as we say in Holland to be more catholic than the pope.

That sentence doesn't make sense. Could you try it again?

In the Microsoft VB string methods are some things standard tested and
solved. By instance the check on the right lenght. That can lead to a better
performance than using the substring.

Cor

 

[Jon Skeet [C# MVP]]

I would be the last to deny that, however as I see how often samples are
given in C# about datalayers which are made static, than I think that your
comment is as we say in Holland to be more catholic than the pope.

That would only be true if I were defending that kind of datalayer vs
one which was more OO.

In the Microsoft VB string methods are some things standard tested and
solved. By instance the check on the right lenght. That can lead to a better
performance than using the substring.

String.Substring tests things too. If any of the parameters specified
are invalid, an exception is thrown, and if the specified length is 0,
string.Empty is returned. It could be that due to the order of some
checks, there are *some* very specific circumstances in which using Mid
performs better. (I'd be interested in seeing what those circumstances
are, however.)

In the vast majority, however - i.e. the calls where Mid ends up
calling String.Substring - Mid will perform worse because it's doing
other things before calling String.Substring.

Jon

 

[Herfried K. Wagner [MVP]]

Jon,

However, you gave the impression that there's no reason not to use Mid.
Here are my reasons:

1) It's not as OO as using a method on the String class

That's not a criterion for me. I see OO as a valuable tool, but I cannot
see any advantages of object-orientation in this particular case over a
procedural approach.

2) There's a direct equivalent in String.Substring

It's not a direct equivalent. For example, I use 'Mid' if I want to make
use of its special 'Nothing' reference handling capability.

3) Users of other languages are more likely to understand Substring

Well, IIRC there are more developers on the world who are able to understand
'Mid' than 'String.Substring', I assume. Remember the popularity of VB6 --
all .NET languages together do not have such a huge number of users.

4) The Microsoft.VisualBasic assembly may not be entirely implemented
in other CLR implementations, whereas System.String certainly will
be

This may apply to any library. I agree with you that it's more likely that
'System.String' is implemented, but I'd consider a VB.NET implementation
without support of "Microsoft.VisualBasic.dll" as an imcomplete solution.

5) Due to being less widely used than System.String, it's more likely
to have bugs. This is a general point about the
Microsoft.VisualBasic assembly, which isn't as widely used as the
equivalents in the System.* assemblies. For instance, last time I
looked hard at Asc and Chr (IIRC) there was distinctly odd behaviour
in terms of which character encoding was actually used. (It depended
on the first use within the app, I believe.)

I didn't take a look at these particular functions. Bugs can be everywhere.
The 'Like' operator of VB.NET has been flawed in VB.NET 7.*, for example.
It has been fixed in the current version. However, this operator could have
been widely used. I do not think that the overall quality of
"Microsoft.VisualBasic.dll" is lower than those of the .NET Framework class
library.

6) It's less efficient as it's performing all the checks that Substring
performs before calling Substring.

Well, sometimes I want this checks to be performed instead of putting them
into my code.

[Maybe I'll find time to reply on the rest later...]

 

[Herfried K. Wagner [MVP]]

Um, yes it does. Having an instance method which acts on an instance of
a class is more OO than having a static method in a separate class to
operate on an instance of the first class.

That's true, but I am not using OO for the sake of using OO. I use OO where
it increases overall productivity (reusability, maintainability, stability)
and I use other approaches in cases where I cannot see any advantages by
using OO.

Some months ago I have talked to a good friend of mine about the solution
taken for strings versus the solution taken for numeric types. The 'String'
class implements instance methods for certain operations which work on the
object they are called on, such as 'String.Substring'. Mathematical
operations however are implemented as shared methods of the 'Math' class.
Why not make 'Cos' an instance method of the 'Double' class? This would
certainly make the code more OO...

 

[Cor Ligthert [MVP]]

Some months ago I have talked to a good friend of mine about the solution
taken for strings versus the solution taken for numeric types. The
'String' class implements instance methods for certain operations which
work on the object they are called on, such as 'String.Substring'.
Mathematical operations however are implemented as shared methods of the
'Math' class. Why not make 'Cos' an instance method of the 'Double' class?
This would certainly make the code more OO...

 

[Jon Skeet [C# MVP]]

That's not a criterion for me. I see OO as a valuable tool, but I cannot
see any advantages of object-orientation in this particular case over a
procedural approach.

It's all about clarity as far as I'm concerned. When you use "Mid",
someone who doesn't know it's a "magical" VB function would be at a
loss to know what's going on. When you use String.Substring, it should
be obvious to anyone who knows *anything* about whatever language is
being used that you're calling a method on the string.

It's not a direct equivalent. For example, I use 'Mid' if I want to make
use of its special 'Nothing' reference handling capability.

Whereas I'd deal with that explicitly in code, as I believe that's
clearer - I suspect that far from everyone knows that special case.

(It's also not directly equivalent in terms of its "basing" of 1 rather
than 0. Again, as the rest of the .NET framework is essentially
0-based, that seems like an inconsistency to me. Yes, it's consistent
with VB6, but I'd hope to move towards a more .NET-centric code base
and away from a VB6-centric code base.)

Well, IIRC there are more developers on the world who are able to understand
'Mid' than 'String.Substring', I assume. Remember the popularity of VB6 --
all .NET languages together do not have such a huge number of users.

That will change, over time however. If you care more about readability
for VB6 developers than for other .NET developers, that's your choice
though. I think it's a reasonable objection for me to make at the same
time.

This may apply to any library. I agree with you that it's more likely that
'System.String' is implemented, but I'd consider a VB.NET implementation
without support of "Microsoft.VisualBasic.dll" as an imcomplete solution.

Well, it would still be a perfectly good ECMA library implementation.
There's a reason why it's *Microsoft*.VisualBasic...

I didn't take a look at these particular functions. Bugs can be everywhere.
The 'Like' operator of VB.NET has been flawed in VB.NET 7.*, for example.
It has been fixed in the current version. However, this operator could have
been widely used. I do not think that the overall quality of
"Microsoft.VisualBasic.dll" is lower than those of the .NET Framework class
library.

Maybe I happened to be unlucky then. It makes sense to me, however,
that the most used code tends to be the most reliable, because bugs are
more likely to get found in the wild and then fixed.

Well, sometimes I want this checks to be performed instead of putting them
into my code.

But they're already performed - in String.Substring! String.Substring
will check whether or not you've given it an invalid length, but if you
call Mid instead of Substring, the check gets made twice.

Jon

 

[Carlos J. Quintero [VB MVP]]

Mathematical operations however are implemented as shared methods of the
'Math' class. Why not make 'Cos' an instance method of the 'Double' class?
This would certainly make the code more OO...

Hi Herfried,

While I see some of your point (and also Jon's one) notice that the Cos
mathematical function would be suitable for an Angle class, but not for a
Double class, since not every Double instance is intended to store an angle.
In fact the Double class is not the best type to store an angle in a OO
world, you would need an Angle class with input validation (0-360 degrees),
measurement system (radians, 360-degrees, 400-degrees, military-degrees),
special handling of "+" and "-" operators (350º + 20º = 10º) , etc.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com

 

[Carlos J. Quintero [VB MVP]]

It's all about clarity as far as I'm concerned. When you use "Mid",
someone who doesn't know it's a "magical" VB function would be at a
loss to know what's going on. When you use String.Substring, it should
be obvious to anyone who knows *anything* about whatever language is
being used that you're calling a method on the string.

Hi Jon,

Notice that with current IDEs you can navigate to the definition of any
"magical" function, we no longer work with blind IDEs. And also, in a OOP
you can have classes with static (C#) / Shared (VB.NET) methods and at least
VB.NET (not sure about C#) allows you to add an "using" / "Imports"
statement for the class (not only for the namespace) and you use just the
name of the function in the code and you lose the same clarity, but I see
your point, and when using shared/static methods I always try to prefix them
with the class to gain clarity.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com

 

[Jon Skeet [C# MVP]]

Notice that with current IDEs you can navigate to the definition of any
"magical" function, we no longer work with blind IDEs.

Sure - but you really don't want to have to keep doing that for
something as basic as taking a substring.

And also, in a OOP
you can have classes with static (C#) / Shared (VB.NET) methods and at least
VB.NET (not sure about C#) allows you to add an "using" / "Imports"
statement for the class (not only for the namespace) and you use just the
name of the function in the code and you lose the same clarity, but I see
your point, and when using shared/static methods I always try to prefix them
with the class to gain clarity.

There are times when static methods make sense. However, to use a
static method acting on a different type when there's a perfectly good
method which is already part of the class seems pretty pointless to me.
Part of an upgrade process? Fine. Part of new code? Preferrably not,
IMO.

Jon

 

[Carlos J. Quintero [VB MVP]]

Hi Jon,

Yes, I agree, I also avoid Mid, Left, etc. I only pointed that you don´t
have to search in the help or Google the definition of a function.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com



"Jon Skeet [C# MVP]" <[email protected]> escribió en el mensaje

There are times when static methods make sense. However, to use a
static method acting on a different type when there's a perfectly good
method which is already part of the class seems pretty pointless to me.
Part of an upgrade process? Fine. Part of new code? Preferrably not,
IMO.

Jon

 

[Cor Ligthert [MVP]]

Jon,

It's all about clarity as far as I'm concerned. When you use "Mid",
someone who doesn't know it's a "magical" VB function would be at a
loss to know what's going on. When you use String.Substring, it should
be obvious to anyone who knows *anything* about whatever language is
being used that you're calling a method on the string.

Yes but all those MS Office users don't know what is a string. While when
they use VBA probably know what is MID.

What do you think there are more. MS Office + VB6 + VB.Net users or

developers who use Java or C or C++ or Javascript or Java or another
program in this language category?

Cor

 

[Jon Skeet [C# MVP]]

Yes but all those MS Office users don't know what is a string. While when
they use VBA probably know what is MID.

What do you think there are more. MS Office + VB6 + VB.Net users or

developers who use Java or C or C++ or Javascript or Java or another
program in this language category?

We're not talking about people who are developing in MS Office or VB6
though - we're talking about VB.NET users.

As I said before:
<quote>
If you care more about readability for VB6 developers than for other
..NET developers, that's your choice though. I think it's a reasonable
objection for me to make at the same time.
</quote>

 

[Herfried K. Wagner [MVP]]

We're not talking about people who are developing in MS Office or VB6
though - we're talking about VB.NET users.

As I said before:
<quote>
If you care more about readability for VB6 developers than for other
.NET developers, that's your choice though. I think it's a reasonable
objection for me to make at the same time.
</quote>

When writing code in VB.NET, readability for VB.NET developers has top
priority. If I'd like to write code readable for "all" .NET developers I'd
choose ILASM .

 

[Jon Skeet [C# MVP]]

When writing code in VB.NET, readability for VB.NET developers has top
priority. If I'd like to write code readable for "all" .NET developers I'd
choose ILASM .

I'd agree that readability for VB.NET developers should be foremost -
but that doesn't affect whether you care more about readability for VB6
developers than for other .NET developers.