using classes vs. modules

[Rory Becker]

Hello Michael,

Really? How is being forced to use a VB6 feature an advantage?

No-one is forcing you to use any VB feature.

We're also not forcing you to stay here and talk about a language that you
clearly don't like.

If you prefer C# then good luck to you ... I hope you continue to be happy
with it.

 

[Harald M. Genauck]

MichaelC,

Really? How is being forced to use a VB6 feature an advantage?

Because this "feature" has an equivalent in C#, where static classes
have the same advantage?

As you now have learned to know that extension methods have to be
declared in a module in VB.NET, you might already know that extension
methods are declared in a static class in C#.

Technically, on CLR level, VB.NET's modules are almost the same as
static classes in C#. With both of them you cannot create instances.
The only, but very little important difference is that modules can't
have a private constructor (no matter, a one liner does solve that task
in a VB.NET module). Modules are simply a syntactical shortcut to
static classes, as you'll save the time of typing the "static" keyword
at any declaration of members.

In C#, static classes are commonly used for libraries (see System.Math,
e.g.). As they aren't "evil" in C#, why should the equivalent in
VB.NET bei "evil" at all?

In VB.NET, using a class having only shared members, is not the same
like a static class. Because of such a class instances may be created.
Even it might be not very interesting creating instances having no
usable members, it might not be the the intention of a developer of
such a class. At least the possibility to create instances seems not
to be clean and consistent, compared to static classes. For that, take
a module in VB.NET, and you'll have a clean "class" that cannot be
instantiated.

Last point: The assumption that VB.NET developers cannot but running
into "bad" VB6 style goes too far. I do know lots of "young"
developers who started programming in .NET, in VB.NET, without ever
knowing of "bad" VB6 styles. And, for example, I myself have started
using OOP principles and architectural models in VB3, being happy to
find more and more OOP in VB4 and finally in VB5/6. Neither in VB.NET
nor in C# I am missing any "bad" "features" that many people, but never
all of them, might have been using in VB6 and earlier.


Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de
"ABOUT Visual Basic" - http://www.aboutvb.de

 

[Michael C]

Because this "feature" has an equivalent in C#, where static classes have
the same advantage?

That is true but in C# the functions don't become global throughout the app.
You need to qualify with the class name. A small but important difference.

As you now have learned to know that extension methods have to be declared
in a module in VB.NET, you might already know that extension methods are
declared in a static class in C#.

Yes, in a class which is a good thing (tm).

Technically, on CLR level, VB.NET's modules are almost the same as static
classes in C#. With both of them you cannot create instances. The only,
but very little important difference is that modules can't have a private
constructor (no matter, a one liner does solve that task in a VB.NET
module). Modules are simply a syntactical shortcut to static classes, as
you'll save the time of typing the "static" keyword at any declaration of
members.

That is true except for the global issue.

In C#, static classes are commonly used for libraries (see System.Math,
e.g.). As they aren't "evil" in C#, why should the equivalent in VB.NET
bei "evil" at all?

Because the functions become global.

In VB.NET, using a class having only shared members, is not the same like
a static class. Because of such a class instances may be created.
Even it might be not very interesting creating instances having no usable
members, it might not be the the intention of a developer of such a class.
At least the possibility to create instances seems not to be clean and
consistent, compared to static classes. For that, take a module in
VB.NET, and you'll have a clean "class" that cannot be instantiated.

You can just create a private constructor. Then you have everything in a
class and cannot create an instance of that class. Best of both worlds.

Last point: The assumption that VB.NET developers cannot but running into
"bad" VB6 style goes too far. I do know lots of "young" developers who
started programming in .NET, in VB.NET, without ever knowing of "bad" VB6
styles. And, for example, I myself have started using OOP principles and
architectural models in VB3, being happy to find more and more OOP in VB4
and finally in VB5/6. Neither in VB.NET nor in C# I am missing any "bad"
"features" that many people, but never all of them, might have been using
in VB6 and earlier.

You use modules. What else do you use? Do you redim arrays? Do you use the
VB only functions such as My?

Michael

 

[Michel Posseth [MCP]]

Even main need not be in a module (vb does support that, surely?)


I'm really not sure what you're trying to say here.


That is an odd thing to say seeing that in VB6 you had to use modules and
we've gone well away from them in dot net. AFAIK the framework itself does
not use modules anywhere.

Actually my last dozen vb6 exe projects only contained one module for the
sub main
even then it was considered bad coding practice to throw everything in a
module

You could do a lot more in VB6 like OOP style , Multithreading etc etc as
people tend to believe you could

The real problem with modules is that methods become completely global
everywhere throughout the app. This is not a good way to program and just
one of the many reasons I prefer C# over VB, many of the bad features are
not there. This forces programmers to at least program a little better.
Some don't even realise they should not be using On Error, having option
strict off, using modules etc.

Michael

I am that kind of coder who also doesn`t like shared classes and shared
methods , but this is just a personal preference and not a guide as you
stated it

You are just like one of my customers , who once started to complain that my
programs looked to nice and functioned to well
because this is not what he had asked for , he just wanted to have a program
that could do the job and not the fancy smooth running product that i made
so he had now the idea that he payed to much , as a rawer program must have
costed me less time .

in my perspective

VB.Net is a Mercedes 500 with full options ( you might use the sunroof ,
stereo etc etc etc or not )
C# is a military equiped Hummer

They are both great cars but they both have there advantages and
disadvantages

Actually the only good reasson i found for modules in VB.Net was to overrule
the builtin methods for better ones ( like a better generic IIF when we did
not yet had the generic if method ) so in that light seen modules can
still be verry handy and it might be a lack for C# maybe they will be
introduced in a future version

regards

Michel Posseth

 

[Harald M. Genauck]

That is true but in C# the functions don't become global throughout
the app. You need to qualify with the class name. A small but
important difference.


Yes, in a class which is a good thing (tm).


That is true except for the global issue.


Because the functions become global.

You can just create a private constructor. Then you have everything
in a class and cannot create an instance of that class. Best of both
worlds.

Yes, you may create a private constructor. But you have not to do so.

And, one may use qualifiers on accessing a module's members. But one
have not to do so.

So if you are expecting VB people to create a private constructor on a
faked static class properly, you even can expect VB people to use
qualifiers on accessing a module's members. But, if you don't expect
least, you cannot expect first.

You use modules. What else do you use? Do you redim arrays? Do you
use the VB only functions such as My?

Redim arrays? If there's a need for it, I do so. Why, otherwise,
write code for things, that VB does do for me in behind?

My functions? These are not VB only. You may use them in C# too.
Like any other library. Or is it bad in any way to use libraries? As
you might know, it commonly is good coding style to avoid writing the
same code twice.


Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de
"ABOUT Visual Basic" - http://www.aboutvb.de

 

[Michael C]

I am that kind of coder who also doesn`t like shared classes and shared
methods , but this is just a personal preference and not a guide as you
stated it

Naturally there is no right and wrong but generally I would say avoiding
anything global is a move in the right direction.

in my perspective

VB.Net is a Mercedes 500 with full options ( you might use the sunroof ,
stereo etc etc etc or not )
C# is a military equiped Hummer

They are both great cars but they both have there advantages and
disadvantages

I keep saying this but I don't think anyone is listening. The difference
between VB and C# is much more minor than most people here seem to think.
You cannot compare them to 2 different cars, if anything they are the same
car with a different paintjob and a few different options.

Actually the only good reasson i found for modules in VB.Net was to
overrule the builtin methods for better ones ( like a better generic IIF
when we did not yet had the generic if method ) so in that light seen
modules can still be verry handy and it might be a lack for C# maybe they
will be introduced in a future version

C# has no global functions like CType so it would be of no use.

Michael

 

[Michael C]

Yes, you may create a private constructor. But you have not to do so.

And, one may use qualifiers on accessing a module's members. But one have
not to do so.

So if you are expecting VB people to create a private constructor on a
faked static class properly, you even can expect VB people to use
qualifiers on accessing a module's members. But, if you don't expect
least, you cannot expect first.

This is what everyone did in C# before we had static classes. Now everyone
declares the class static so I don't se why it's such an issue to expect
them to create a private constructor in VB.

Redim arrays? If there's a need for it, I do so. Why, otherwise, write
code for things, that VB does do for me in behind?

An array is a fixed block of memory, you should only use an array if you
intend never to change its size. If you need to change the size then use a
list.

My functions? These are not VB only. You may use them in C# too. Like
any other library. Or is it bad in any way to use libraries? As you
might know, it commonly is good coding style to avoid writing the same
code twice.

The My namespace or class is what I'm talking about.

 

[Andy B.]

The My namespace or class is what I'm talking about.

What is the My namespace/class?

 

[Rory Becker]

Hello Andy B.,

What is the My namespace/class?

using VB2005 or better you can type...
-------------------------------
My.
-------------------------------
....and have access to a sort of .Net speeddial system.

Think of it as as some additional library functionality of things that beginners
in each area might not know how to do.

Nice in a way. I quite like....

 

[Andy B.]

using VB2005 or better you can type...
-------------------------------
My. -------------------------------
...and have access to a sort of .Net speeddial system.

Think of it as as some additional library functionality of things that
beginners in each area might not know how to do.

Kind of like coding shortcuts?

Nice in a way. I quite like....

I probably will too. Will have to look at it.

That seemed easy enough...grin!

The real shame is that such beginners can't push a button to convert the
speeddial into the real code so they can see how it works.

How do you do that? What button do you push?

 

[Tom Shelton]

Hello Andy B.,


using VB2005 or better you can type...
-------------------------------
My.
-------------------------------
...and have access to a sort of .Net speeddial system.

Think of it as as some additional library functionality of things that beginners
in each area might not know how to do.

Nice in a way. I quite like....

Which is exactly why I don't like My.

 

[Rory Becker]

Hello Andy B.,

How do you do that? What button do you push?

That was just my point... you can't. There isn't one

This basically means that if My doesn't produce exactly what you're after,
you have to code from scratch, without any knowledge of how My did as much
as it did do.

IMHO MY should be reimplemented as code generation rather than as a library.

In this way we could see exactly how it was working. Ideally only the bits
that were used would be included.

Just an Idea.... And I've not thought it through very well

 

[Cor Ligthert[MVP]]

Which is exactly why I don't like My.

Do you have anything against beginners.

To be honest I had not that idea from you.



I don't like as well not the My namespace, but that does not mean that I
tell that beginners should not use it.
There are more important things to do when you come from VB6 then make
direct the best OOP programs.

However, there is no problem for me as we have different ideas about this.



Cor

 

[Tom Shelton]

Do you have anything against beginners.

To be honest I had not that idea from you.

I have nothing against beginners. I enjoy helping them when I can. I guess
my overall problem with My is that it obscures a lot of the inner workings of
the framework - which, is not necissarily bad. As developers we do it all the
time - we wrap framework functionality in to more convienient methods... But,
to do that you need a knowledge of the framework. It seems to me, that the My
namespace can actually impede the progress of a beginner because if they need
to go beyond the functionality provided - they have no idea where in the
framework to look. It's just my opinion, but I think that one of the most
important task a new .NET developer (VB or C#) should perform is to learn the
framework. I don't mean every minute detail - but, they should have a general
understanding of it's orginization and general functionality....

I don't like as well not the My namespace, but that does not mean that I
tell that beginners should not use it.

I don't either - I just never include it's use in my replies

 

[Cor Ligthert[MVP]]

I don't either - I just never include it's use in my replies

Me either, or it should be for things as ping.

That is exactly what I do like less in C#, there are no simple solutions in
C# for in fact all day problems as they don't have those accepted from VB.

Cor

 

[Michael C]

That is exactly what I do like less in C#, there are no simple solutions
in C# for in fact all day problems as they don't have those accepted from
VB.

Are you saying there are no simple solutions to everyday problems in C#. Can
you give some examples?

 

[Tom Shelton]

Are you saying there are no simple solutions to everyday problems in C#. Can
you give some examples?

While I actually ran into a problem today that is most difficult in VB...
Custom iterator for a Linq query. Easy-peasy in C# with the good old yield
return - not so much in VB.

 

[Michael C]

While I actually ran into a problem today that is most difficult in VB...
Custom iterator for a Linq query. Easy-peasy in C# with the good old
yield
return - not so much in VB.

VB has no yield keyword and nothing equivelant? Yikes!! That's my favourite
functionality at the moment, my current app has 1400 lines of code extending
linq. This is a pretty serious ommission imo. Linq is missing a lot of
functionality which is easy to adding using yield return. If it's not there
all this functionality would be difficult to add. Yet another way VB is
meant to be easier to use but just ends up being more difficult.

Michael

 

[Harald M. Genauck]

This is what everyone did in C# before we had static classes. Now
everyone declares the class static so I don't se why it's such an
issue to expect them to create a private constructor in VB.

Rather the same with me: I don't see, why it's such an issue to expect
them to use qualifiers on accessing their module's members.

Why going a workaround style, if there's an appropriate thing that
fulfills exactly the requirement?

An array is a fixed block of memory, you should only use an array if
you intend never to change its size. If you need to change the size
then use a list.

Sure, for most specs you're right.

The My namespace or class is what I'm talking about.

Me too.


Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de
"ABOUT Visual Basic" - http://www.aboutvb.de

 

[Michael C]

Rather the same with me: I don't see, why it's such an issue to expect
them to use qualifiers on accessing their module's members.

Why going a workaround style, if there's an appropriate thing that
fulfills exactly the requirement?

A couple a reasons I can think of are that you only have to remember the
private constructor in 1 place vs potentially hundreds or thousands of
places where you need to qualify the module name. Second reason is that a
shared function forces developers to qualify the function name. If you want
to qualify the function then having a built in method that forces developers
to do it the correct way is a *really* good thing (tm). THis is especially
true in a team environment.

Sure, for most specs you're right.

But you still use redim in some places?

Me too.

Oh ok, it misread your post. You do need to add a reference to some library
with the name VisualBasic in it I suspect? I can't see a lot of C#
developers doing this. )

Michael