Classes vs. Modules

Z

Zytan

I've read the docs on this, but one thing was left unclear. It seems
as though a Module does not have to be fully qualified. Is this the
case? I have source that apparently shows this.

Are modules left-over from VB6, and not much used anymore? It seems
that it is better to require Imports or use fully qualified names for
functions in other classes/modules, but a Module doesn't require this,
cluttering the global namespace. It seems using a class with shared
functions/subs is better.

Any recommendations?

Zytan
 
L

lord.zoltar

I've read the docs on this, but one thing was left unclear. It seems
as though a Module does not have to be fully qualified. Is this the
case? I have source that apparently shows this.

Are modules left-over from VB6, and not much used anymore? It seems
that it is better to require Imports or use fully qualified names for
functions in other classes/modules, but a Module doesn't require this,
cluttering the global namespace. It seems using a class with shared
functions/subs is better.

Any recommendations?

Zytan
Click to expand...

I still sometimes use modules for global variables and functions... I
think it was mentioned a while ago in this group (search for it, I'm
not sure) that Modules actually get compiled into static classes with
shared static members and functions...
 
A

Armin Zingler

Zytan said:
I've read the docs on this, but one thing was left unclear. It
seems as though a Module does not have to be fully qualified. Is
this the case? I have source that apparently shows this.

Are modules left-over from VB6, and not much used anymore? It seems
that it is better to require Imports or use fully qualified names
for functions in other classes/modules, but a Module doesn't require
this, cluttering the global namespace. It seems using a class with
shared functions/subs is better.

Any recommendations?
Click to expand...

It's been discussed about 1 mio times, so please search this group first.
http://groups.google.com/groups/sea....public.dotnet.languages.vb+insubject:module*


Armin
 
Z

Zytan

I still sometimes use modules for global variables and functions... I
think it was mentioned a while ago in this group (search for it, I'm
not sure) that Modules actually get compiled into static classes with
shared static members and functions...
Click to expand...

Ok. That's interesting.

I try to avoid global vars like the plague, as do most, so I cannot
see why anyone would still want to use this. If you're gonna have a
'global var', it seems better to at least be in a class, where you
confine it to a certain location.

Zytan
 
L

lord.zoltar

Ok. That's interesting.

I try to avoid global vars like the plague, as do most, so I cannot
see why anyone would still want to use this. If you're gonna have a
'global var', it seems better to at least be in a class, where you
confine it to a certain location.

Zytan
Click to expand...

I know... I don't like globals either, but they do creep up
occasionally... I rarely have need for more than one or two. I used
modules a bit more when porting an old VB6 project. It was just easier
to leave stuff in them as long as it compiled. those parts are slowly
being re-written.
I also like Modules for situations like the Math class. I never need
to create an instance of Math, I just need functions like sine,
cosine, and constants, like Pi.
 
H

Herfried K. Wagner [MVP]

Zytan said:
http://groups.google.com/group/micr...read/thread/900bd6e5b4c83939/dffa6556bc656471
"There is never a reason to use a module execpt if you have that
already in
your VB6 converted program."

Exactly what I thought. Good enough.
Click to expand...

Well, I have to disagree.

Personally, I do /not/ use modules to store variables and program state. I
use modules only in very few cases: The project's main entry point is
placed in a module 'Program'. In addition, common functions are placed in
modules if their use makes sense throughout the project, similar to
"Microsoft.VisualBasic.dll" and its modules. In this case modules are used
to structure a huge set of functions, but make them easily accessible in
IntelliSense everywhere.
 
S

Scott M.

I don't know if I agree with that. A module can be used as a starting point
for your application along with a Sub Main. This can be helpful in
directing the flow of the application startup.
 
Z

Zytan

I know... I don't like globals either, but they do creep up
occasionally... I rarely have need for more than one or two. I used
modules a bit more when porting an old VB6 project. It was just easier
to leave stuff in them as long as it compiled. those parts are slowly
being re-written.
Click to expand...

Yeah, understood. I agree. For VB6, it's best to leave as is, until
you have time to rewrite. But, this isn't a good starting point to
judge how new code should be (and I don't think this is what you are
trying to say, so I think we agree).
I also like Modules for situations like the Math class. I never need
to create an instance of Math, I just need functions like sine,
cosine, and constants, like Pi.
Click to expand...

Yes, exactly. This is precisely what I want. But... it appears you
can just call these function without requiring Math.Pi, but just by
saying Pi. I don't like this. (Maybe I am wrong about this? But,
that's what the docs imply and source code examples I've seen imply.)

Zytan
 
Z

Zytan

Personally, I do /not/ use modules to store variables and program state. I
use modules only in very few cases: The project's main entry point is
placed in a module 'Program'. In addition, common functions are placed in
modules if their use makes sense throughout the project, similar to
"Microsoft.VisualBasic.dll" and its modules. In this case modules are used
to structure a huge set of functions, but make them easily accessible in
IntelliSense everywhere.
Click to expand...

Understood. Thanks. I guess I'm paranoid about having things
floating around, so I want them under something, say Math.Pi instead
of just Pi.

Zytan.
 
Z

Zytan

I don't know if I agree with that. A module can be used as a starting point
for your application along with a Sub Main. This can be helpful in
directing the flow of the application startup.
Click to expand...

Thanks for your input, Scott.

Zytan
 
A

aaron.kempf

modules are PRACTICAL and classes do not allow code-reuse.

don't listen to these dipshits around here;80% of VB6 develoeprs NEVER
WROTE A CLASS

now WHO IN THE **** AUTHROIZED MICRSOFT TO FORCE A FEATURE UPON US
THAT WE DO NOT USE?

my class-less code runs faster than any crap you guys 'write'

-Aaron
 
A

aaron.kempf

uh use a module so that you can reuse a method in a class?

it's called CODE REUSE

not everything fits into a class

-Aaron
 
A

aaron.kempf

uh
more likely 'THERE IS NEVER A REASON TO USE A _CLASS_'

VB IS DEAD
AND NO ONE CARES

IF THERE WAS A HELL
I WOULD SEND MICROSOFT THERE

**** them for killing our language

**** that mother ****ing company and all the gooks and chinks that
work there

-Aaron
 
T

Tom Leylan

Just stick with your original concerns and forget about modules. Yes of
course one can use a module, one can place their Sub Main in a module and
they can put commonly used functions and procedures in a module however it
isn't necessary and lots of people (including me) don't.

I too have a Sub Main but mine just happens to be a Shared method of my
standard application class. This application class can contain any routines
common to the app as well so one continues to reap all the benefits of a
class implementation with no downside. Additionally should it ever be
needed I can convert (or pay somebody to convert) the entire app to C# or
even Java because there is nothing "VB-only" about the application. The
class, method, property modelling will translate across the board.

I'll suggest you keep your options open.
 
T

Tom Shelton

I don't know if I agree with that. A module can be used as a starting point
for your application along with a Sub Main. This can be helpful in
directing the flow of the application startup.
Click to expand...

So can a class.
 
S

Scott M.

But if you were to create a class that handled program flow during startup,
you'd be doing extra work to get you to exactly what you could have
automatically with a module and Sub Main.
 
T

Tom Shelton

But if you were to create a class that handled program flow during startup,
you'd be doing extra work to get you to exactly what you could have
automatically with a module and Sub Main.
Click to expand...

It's not any extra work to make a class the startup object versus a module -
well except for maybe making a private sub new so that no one can make
instances of your Program class.

Of course, in VB 2005 - you pretty much have to use a form as your startup
object anyway. You dont' get to do a submain. Well, that isn't strictly
true, but if you want to use the application framework that VB.NET provides
then you do (and why wouldn't you - visual styles, single instance app,
settings, etc).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Namespace around API calls 4
Use of NAMESPACE 1
Problem Creating DLL Entry Point 2
Namespace-class hierarchy for a library of helper functions 4
Concept ? about Modules vs Classes 8
Same sub in two modules, wrong one gets called? 2
Calling Access based Modules from Vb.Net 1
Declaring variables in Module vs. Public 5

Top