Classes vs. Modules

  • Thread starter Thread starter Zytan
  • Start date Start date
Zytan wrote:
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.
Click to expand...
<snip>

Yes, modules do put all public elements in the "global" namespace they
belong.

Note, however, that while a module is usually placed at the project's
namespace, it doesn't need to be so. A module in a specific namespace
won't appear globally in the project's namespace, only in the
immediate namespace the module is contained. Outside the namespace
you'd still need to prefix the method call with the namespace -- or
import the namespace altogether.

<aircode>
Namespace Globals
Module SomeModule
Sub SomeSub
'...
End Sub
End Module
End Module

Class SomeClass
Sub New
SomeSub '<-- Error
Globals.SomeSub '<-- Ok
Globals.SomeModule.SomeSub '<-- Ok, also
End Sub
End Class

'In another file
Imports Globals

Class SomeOtherClass
Sub New
SomeSub '<-- Ok
SomeModule.SomeSub '<-- ditto
End Sub
End Class
</aircode>

If this behavior isn't what you want, I suggest you use shared methods
in classes, then.

On the other side, if "global" methods is exactly what you want, or
you don't care because you'd Import the class anyway (making the
shared methods global), or still, you want global methods inside a
specific namespace, then go ahead and use a module, instead.

HTH.

Regards,

Branco.
 
Yes, modules do put all public elements in the "global" namespace they
belong.

Note, however, that while a module is usually placed at the project's
namespace, it doesn't need to be so. A module in a specific namespace
won't appear globally in the project's namespace, only in the
immediate namespace the module is contained. Outside the namespace
you'd still need to prefix the method call with the namespace -- or
import the namespace altogether.

<snip>

If this behavior isn't what you want, I suggest you use shared methods
in classes, then.

On the other side, if "global" methods is exactly what you want, or
you don't care because you'd Import the class anyway (making the
shared methods global), or still, you want global methods inside a
specific namespace, then go ahead and use a module, instead.

HTH.
Click to expand...

Branco, yes, this helps a lot. Thanks for your very informative
post. I had thought about making modules in namespaces, but I am not
comfortable with it due to lack of experience. But, I can see how
this helps. I guess the lack of need to use the module name itself
throws me off, even in this case. Yes, the namespace is required
(unless you use Imports), but the module name can always be missing.
I suppose most people use Imports for many things, though, and they
are used to this.

In any case, thanks for the in depth reply.

Zytan
 
Zytan wrote:
I guess the lack of need to use the module name itself
throws me off, even in this case. Yes, the namespace is required
(unless you use Imports), but the module name can always be missing.
I suppose most people use Imports for many things, though, and they
are used to this.
Click to expand...
<snip>

I think that simply importing a namespace into the file is evil (or
something close to it). My (personal, mind you) rule of thumb is, if I
must use Imports, then I must create an alias to it:

Imports SysThread = System.Threading
Imports SysRegex = System.Text.RegularExpression

As opposed to:

Imports System.Threading
Imports System.Text.RegularExpression

Don't know if this relates to what you're talking about, and my
apologies if it drifts to OT.

Regards,

Branco.
 
that would sure be interesting to me

so I can make a class named 'aaron' and I can put functions in it..
and I can reuse those functions without instantiating a class?

I just don't like all of the dependencies between that style of
writing; it makes me sick to think about it
 
I don't need to

startup a vb6 forms app.. and startup a vb 2005 forms app

it's obvious to me which is faster
 
clutter the global namespace?

are you ****ing kidding me?

does this make the app slower?

does it make carol in accounting enter data _FASTER_ ??
 
yeah

module aaron

module matt

I can refer to aaron.method1 or matt.method2 just as easily as with a
class; but I don't need to instantiate an instance of the class first
 
Cor

I strongly

I militantly, agree

80% of VB6 developers 'never used a class' why did we need to get this
crap shoved down our throats?
 
are you ****in kidding me bro?

you think that vb6 was build on a prior version of the .net runtime?

ROFL

yeah, vb6 had classes; it didn't support inheritence

but I'm over it

taking a module and pasting it into a class and adding 2 lines of code
does _NOTHING_ for you.
I had a co-worker who used to do that and my stupid ****ing manager
thought that he was such a great programmer--- because he used clases

and I was like 'uh, he has no error-handling, he has no structure, no
consistency'

and she didn't give a crap; all she liked was that it was a class

it kinda blew my mind; I thoght that it wa hilarious

he would take a module and paste it into a class without rewriting the
module into logical methods; he wouldn't even make anything private;
it was the ugliest code i've ever seen in my life

little prissy kid named 'craig'
 
lloyd

I just said that 80% of vb6 programmers 'never used a class'

why did we need to get enlightened?

does moving to classes make our code faster?
 
Tom

I am so sorry that you had a fag computer science professor

it doesn't mean that classes make your code run faster
it doesn't simplify

and it doesn't support reuse
 
tom

the basic variable naming convention was from the friggin 80s dude; I
mean.. nobody used that recently; except one kid I knew in insurance;
he still used that

and it wasn't a matter that string variables _MUST_ end with a $
symbol

I just found this great book about basic; it is literally from 1982..
it reminds me of the good ole days

it's got the best illustrations in it
 
Scott;

re: 1.5mb runtime; keep on preaching the good word, bro

maybe someday the framework will get under 10mb

-Aaron
 
no dude

an extra minute here and there adds up

that is why I can out-develop you with my hands tied behind my back

-Aaron
 
tom

if you're a c# fag then get the **** out of my newsgroup

C# is to fight java; which I claim was 'never a threat'

-Aaron
 
fully agree spam catcher

I mean-- it's really obvious to me that modules should be used
whenever possible so you don't need 12 different copies of the same
method

(since vb 2005 and c# don't support polymorphism)
 
That's news to me. I use polymorphism in both VB 2005 and C# 2005. Maybe
what you really mean is that both languages require (optional in VB 2005)
strongly typed parameter passing and VB 6 and earlier let you write sloppy
code that you had to runtime check every single parameter.

Mike Ober.
 
fully agree spam catcher

I mean-- it's really obvious to me that modules should be used
whenever possible so you don't need 12 different copies of the same
method

(since vb 2005 and c# don't support polymorphism)
Click to expand...

Sure they do, in VB look up Overload for starters.
 
Zytan said:
Branco, yes, this helps a lot. Thanks for your very informative
post. I had thought about making modules in namespaces, but I am not
comfortable with it due to lack of experience. But, I can see how
this helps. I guess the lack of need to use the module name itself
throws me off, even in this case. Yes, the namespace is required
(unless you use Imports), but the module name can always be missing.
I suppose most people use Imports for many things, though, and they
are used to this.
Click to expand...

Personally I import all namespaces containing types I am using. I hate
namespace-qualified types inside the implementation because they blow up
code resulting in very long lines. In general I qualify types (classes,
structures, ...) and functions (in modules) only if there would be a name
clash otherwise.
 
Back
Top