Classes vs. Modules

  • Thread starter Thread starter Zytan
  • Start date Start date
Zytan,

VB 6.0 does support classes. Our resident malcontent maintains that NOBODY
who ever programmed in VB Classic ever used classes, but he has not ever
tried to actually PROVE that his assertions were true. However, if you go to
the MSDN page below, you'll see that MS did have class support in VB 6.0...

https://msdn.microsoft.com/library/...98/html/vbconaddingclassestoolecomponents.asp

Most of the users on this group ignore Aaron's posts or add him to their
message killfile, because all he has ever done is come in here and attack
folks for trying to improve their skills and become more proficient at their
jobs.

Bruce
 
I worked on an app in VB6 and it had over 500 classes. So if whoever is
saying this can eat his words.
 
We've been over this before on other threads. The module you think you
wrote has been determined to be a class (if you believe what others posted
here about modules) so you haven't constructed a module but rather a class
with a VB-only name attached to it. What is the point of that? And you
don't have to answer I can almost list the names of the people who like
modules and those who don't see a need from the other threads.

Do like the BASIC variable naming convention that string variables must end
with a $ symbol? Would it be a fair guess that neither you nor Herfried
mind that that convention was dropped? So is this a matter of figuring out
which conventions you guys will let drop from the language. :-)

Can you subclass your module? Is it serializable?
 
I'm going to have to bow out of the thread after this as it's drifting away
from facts and turning into a language war.

I see that the other replies about VB6 and classes didn't take a moment out
to mention that VB6 had nothing to .Net and there was no prior version of
..Net that was implemented in VB6. Rather than rely on the musings of a few
people here I suggest you look online for a trustworthy source on the
history of Visual Basic.

It isn't BTW enough (from a computer science standpoint) that VB6 had
"classes" and object orientation isn't defined as having classes. VB6
lacked "implementation inheritance" and inheritance is considered a
necessity in an OOP language. VB6 isn't an object-oriented language but it
did support classes. We tend to call such languages object-based.
 
Tom, I think this really comes down to "you say tomatoe and I say tomato".
I have had this conversation many times albeit about other aspects of VB vs.
the Framework. Should VB language functions be used over .NET Framework
classes and methods, for example? The debate rages on.

What I do think is that no one can say with certainty "do" or "do not" use
modules. They exist and by that very fact, they are viable. I never
indicated that they "should" be used, nor did I even indicate that they
should "always" be used. In fact, I rarely use them. But in certain
situations, they serve a purpose and can be of help.

If you really want to have an objective conversation here, you must be
willing to concede that your comments about VB legacies are your opinions
and not facts. I happen to largely agree with you personally, but that
doesn't change the fact that it's just my preference/opinion, it doesn't
make it gospel.
 
An application that starts from the command line with different potential
switches attached is the one I had in mind. Another could be applications
that start differently based on the user logged into the domain. Really,
any application that has multiple startup paths where those startup paths
are determined in a non-GUI way.
 
Does that imply VB6 didn't use classes?

Sure! VB 6.0 was Object-Based, but not fully Object Oriented. It had
classes and almost all OO functionality minus the all-important inheritance.
I thought it was based on a
prior version of the .NET run-time, and that that was still class
based.
Click to expand...

Not at all! Before VB .NET 2003, there was VB 6.0 wich used a much simpler
runtime (MSVBVM60.dll - 1.5 MB). There was no .NET then.
 
Not sure Scott. Are you seeing other posts by Robin? Or did you
inadvertently add him to your killfile?
 
In other threads (and these were recent) I wrote much the same thing. I
specifically mentioned that people who use modules and/or functions like
UCASE() would be unlikely to change due to anything I wrote. I specifically
mentioned that if I was trying to influence anybody, it would be the people
who have yet to adopt a methodology. And I generally suggest they do more
than read a VB newsgroup in order to make an informed decision.

All I am asking from you is when you write "in certain situations" that you
define one of them so people reading this (and these message exist forever)
will understand when they should choose a module over a class.

If the extra work you mentioned takes a week I'll concede the point, if the
extra work is one minute I'd say the word "extra" is a bit of a stretch.
 
Scott: I just don't know where you are coming from on this. Have you tried
placing Sub Main in a class and your command line switches didn't work or
are you imagining it could be problematic and avoiding it as such?

I will guarantee you that my standard app framework supports both GUI and
console apps and that both start with exactly the same class and the same
Sub Main. I simply change the build setting on the compiler. And of course
I can easily read the command line switches and "start differently" based
upon the user. Seriously if I couldn't handle such trivial things using my
app class I would have used a module yet I haven't.

Check with Cor and others and they will explain that a module is in fact a
predefined class in VB.Net.


Scott M. said:
An application that starts from the command line with different potential
switches attached is the one I had in mind. Another could be applications
that start differently based on the user logged into the domain. Really,
any application that has multiple startup paths where those startup paths
are determined in a non-GUI way.
Click to expand...
 
Zytan said:
Does that imply VB6 didn't use classes? I thought it was based on a
prior version of the .NET run-time, and that that was still class
based.

Zytan
Click to expand...

VB6 was pre-.Net. Technically, it had classes, but not true OO
capabilities.

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 someting 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 beter 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
 
Scott,

Never thought about that Tomatoes and tomato. I say always colour and you
say color.
But a good sample.

Cor
 
Tom,

Tom Leylan said:
We've been over this before on other threads. The module you think you
wrote has been determined to be a class (if you believe what others posted
here about modules) so you haven't constructed a module but rather a class
with a VB-only name attached to it.
Click to expand...

In the current implementation of .NET which VB is based on, it's based on
classes under the hoods. However, the concept of modules in VB exists
already longer than .NET exists and modules are clearly not the same as
classes are.

Semantically modules and classes are entirely different. Modules are a
loose grouping construct whereas classes represent instantiable entities
(there are a few exceptions where classes cannot be instantiated, but often
the reason for that is that their instances would not form a complete
entity. That's why I think that modules are an important feature. They
simply cannot be mimicked using a class (in VB/C# semantics, not IL
semantics) because classes are classes and modules are modules.
Do like the BASIC variable naming convention that string variables must
end with a $ symbol? Would it be a fair guess that neither you nor
Herfried mind that that convention was dropped?
Click to expand...

In this particular case I don't see any reason for dropping the convention.
However, I'd prefer if the IDE turned 'Dim i%' into 'Dim i As Integer'
automatically.
Can you subclass your module? Is it serializable?
Click to expand...

As modules do not form what I call entities, I don't see a reason for
subclassing and serialization. Namespaces cannot be serialized too,
although they are a language construct. Modules and classes have (from a VB
point of view) different semantics and thus different characteristics
(operations that can be performed, ways to make use of them, ...).
 
Cor,

Cor Ligthert said:
My point is that a class (in Dutch the word is almost the same and has the
same meaning as in English) tells someting 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 beter name for me for that.
Click to expand...

I agree. Overloading the meaning of 'Class' for different things is hardly
a good idea.
 
All I am asking from you is when you write "in certain situations" that
you define one of them so people reading this (and these message exist
forever) will understand when they should choose a module over a class.
Click to expand...

I've already responded to your request, but my first response (in certain
situations) is perfectly valid. It just seems that you are up on a soapbox
here.
If the extra work you mentioned takes a week I'll concede the point, if
the extra work is one minute I'd say the word "extra" is a bit of a
stretch.
Click to expand...

That's your "opinion" and you are entitled to it. If I can find something
that saves me a minute every so often and it does just what I need it to,
I'll take the extra minute.
 
Tom Leylan said:
Scott: I just don't know where you are coming from on this. Have you
tried placing Sub Main in a class and your command line switches didn't
work or are you imagining it could be problematic and avoiding it as such?
Click to expand...

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.

No one said that classes wouldnt do (and that seems to be your stance here).

I will guarantee you that my standard app framework supports both GUI and
console apps and that both start with exactly the same class and the same
Sub Main. I simply change the build setting on the compiler. And of
course I can easily read the command line switches and "start differently"
based upon the user. Seriously if I couldn't handle such trivial things
using my app class I would have used a module yet I haven't.
Click to expand...

See my comments above.
Check with Cor and others and they will explain that a module is in fact a
predefined class in VB.Net.
Click to expand...

Thanks but I don't need the homework assignment. I know exactly what a
module is and all I've said here is that in some situations they are easier
to use. You seem very threatened by this statement.
 
Must have. I don't see anything from Robin in this entire thread.


Bruce W. Darby said:
Not sure Scott. Are you seeing other posts by Robin? Or did you
inadvertently add him to your killfile?
Click to expand...
 
There's only been one post by me (Robin) *in* this entire thread. Do you
see this one?

Robin S.
----------------------
 
Back
Top