Classes vs. Modules

  • Thread starter Thread starter Zytan
  • Start date Start date
I'm so sorry that you are having such a hard time Tom. To answer your
question, no I haven't. But, that what not the OP. Modules are *another*
way of handling such things. I find them easier for these situations than
custom classes. I find them quicker to set up and use than custom classes
and I find them to make more sense from a *flow* standpoint in these
situations.

I'm sorry Scott, but you are making absolutely no sense here. The
fact is that it takes almost exactly the same amount of work to put
your sub main in a class as it does in a module. There is hardly any
difference here, except for the addition of the shared keyword on the
sub main - and that is what happens automatically if you use a module.

There is no situation that I can think of where a module is superior
or significantly easier then a class. That could be because I do 99%
of all my work in C#, and there is no concept of a module there...
The closest thing is the static class added in C#2.0 - which is a way
to get the compiler to enforce what most of us do anyway - create a
class with a private constructor and all static methods :)

Now, I'm not saying that you shouldn't use Modules. Your style is
your style. I don't use them when I do VB work, but that is my
choice. The only thing I object to in your statement is the
implication that it is more work to use a class.... Simply not true -
at least in any significant manner.
 
Oh, there you are. I was hiding behind the Sycamore TreeView over there.

You guys were doing such a great job discussing this, I didn't really need
to stick my two cents' worth in here. :-)

Robin S.
------------------------------------
 
Thanks! And thanks for not asking what I was doin' over there behind the
Sycamore. ;-)


Robin S.
--------------------------------
 
I try to avoid global vars like the plague, as do most, so I cannot
see why anyone would still want to use this.

For redundant functions it doesn't make sent to need to instaniate
everytime just to use em :-)
 
For redundant functions it doesn't make sent to need to instaniate
everytime just to use em :-)

You don't need to - just make the methods/properties shared. For example
- System.Math. You don't have to create one to use it's functionality...
 
Tom,

Read the comments from Herfried and me, it is seldom that we agree so much,
so there must be something.

Cor
 
Tom,

Read the comments from Herfried and me, it is seldom that we agree so much,
so there must be something.

Cor

Cor,

I have read both your comments - and I have to respectfully disagree
with them. Especially the notion by Herfried that a module is a loose
grouping of functions. In my mind a module should - like a class -
have single purpose. All functionality in that module should be
related - like a class.

Anyway, I'm not here to try and convince anyone to my way of
thinking. Everyone has their own style and their own ideas about how
things should be done. My idea is to avoid module and use a class
with shared methods - you and Herfried like to use modules. That's
ok. It was an interesting discussion at least :)
 
Tom,

I think you misinterpret what we want to say.

A shared class is not a class, it is our opinion a created couple of words
(not even one) to describe a memory part with no object behaviour. That
while there is for that one nice word, what describes that "Module".
Therefore don't make it difficult for newbie's who want to learn what is
OOP. Use a class for a to instance object. Use Module for a piece of code
permanent and shareable in the program.

Cor
 
Tom Shelton said:
I have read both your comments - and I have to respectfully disagree
with them. Especially the notion by Herfried that a module is a loose
grouping of functions. In my mind a module should - like a class -
have single purpose.

I don't disagree :-). The Visual Basic Runtime Library's function library
and its modules is IMO a good example on how using modules is a good idea.
It's pretty clear that using modules to group things that are not related to
each other is as useless as placing them in the same class.
 
You don't need to - just make the methods/properties shared. For
example
- System.Math. You don't have to create one to use it's
functionality...

Yes, I meant shared functions - I realized the ambiguity of my message
after I posted it.
 
Tom,

I think you misinterpret what we want to say.

A shared class is not a class, it is our opinion a created couple of words
(not even one) to describe a memory part with no object behaviour.

I'm not so sure about that... Even SmallTalk has the concept of class
methods vs instance methods (at least, I am led to believe that - I
don't know SmallTalk myself). The idea of class methods (shared
methods) has been around for sometime.

Are they a fully OO concept? Hmmm... I would have to give that some
thought.
That
while there is for that one nice word, what describes that "Module".
Therefore don't make it difficult for newbie's who want to learn what is
OOP.

I'm not trying to make it difficult on anyone. It's obvioulsy a
concept that a lot of people have different oppinions on. And who is
right? I am not convinced yet that a shared (static) class is not an
OOP construct.
Use a class for a to instance object. Use Module for a piece of code
permanent and shareable in the program.

I will think about this some more. Maybe I'll agree with you :)
 
I don't disagree :-). The Visual Basic Runtime Library's function library
and its modules is IMO a good example on how using modules is a good idea.
It's pretty clear that using modules to group things that are not related to
each other is as useless as placing them in the same class.

Then we are in agreement for the most part :) I'm not so sure that I
would ever prefer a module over a class yet though....
 
I see this one. Perhaps you replied to someone that I have on my kill list
so I didn't see that branch!
 
Yes, it was a response to Aaron Kempf. Otherwise, I didn't feel you guys
needed any help discussing this issue; you were doing great without my
input. ;-)

Robin S.
---------------------------
 
My point is that a class (in Dutch the word is almost the same and has the
same meaning as in English) tells something about a type. A shared class
tells nothing, it is a stand alone object not something that describes a
group.

A module is a much better name for me for that.

For me it is more that it is not the right word in C languages as well. I
would propose to call it there as well modules.

Cor

I agree with this. Classes are types. Modules are just a list of
functions, there is no type. I think C languages should have this
term, as well. It suits what it actually is much better. (Or...
allow classes to 'be' modules in that sense, without required 'hacks'
by making everything 'shared' / 'static'. I think a new name, Module,
is better than this idea.)

But... am I just stupid, or do Modules place everything into the
global namespace? This is what I dislike about them. So, I'll use
classes, instead, for this one reason alone.

Zytan
 
Back
Top