Classes vs. Modules

[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

[lord.zoltar]

On Feb 9, 3:15 pm, "Zytan" <[e-mail]:

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

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...

[Armin Zingler]

"Zytan" <zy**********@yahoo.comschrieb

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?

It's been discussed about 1 mio times, so please search this group first.
http://groups.google.com/groups/sear...ject%3Amodule*
Armin

[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...

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

[Zytan]

It's been discussed about 1 mio times, so please search this group first.http://groups.google.com/groups/sear...3Amicrosoft.pu...

>
Armin

Will do. I'm surprised a generic google search didn't return these
results, it usually does at the bottom of the first page of results.
Maybe it's the personalized results stopping it.

Zytan

[Zytan]

Any recommendations?

>From an MVP (Cor):

http://groups.google.com/group/micro...fa6556bc656471
"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.

Zytan

[lord.zoltar]

On Feb 9, 4:17 pm, "Zytan" <[e-mail]:

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...

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

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.

[Herfried K. Wagner [MVP]]

"Zytan" <zy**********@yahoo.comschrieb:

>Any recommendations?

>>From an MVP (Cor):

http://groups.google.com/group/micro...fa6556bc656471
"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.

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[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.
"Zytan" <zy**********@yahoo.comwrote in message
news:11**********************@l53g2000cwa.googlegr oups.com...

>Any recommendations?

>>From an MVP (Cor):

http://groups.google.com/group/micro...fa6556bc656471
"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.

Zytan

[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.

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.

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

[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.

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.

[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.

Thanks for your input, Scott.

Zytan

[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 FUCK 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

[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

[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

fuck them for killing our language

fuck that mother fucking company and all the gooks and chinks that
work there

-Aaron

[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.

"Zytan" <zy**********@yahoo.comwrote in message
news:11**********************@k78g2000cwa.googlegr oups.com...

>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.

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.

[aaron.kempf]

'common functions' dont belong in a class?

SO WHY USE A CLASS _EVER_?

-Aaron

[Tom Shelton]

On 2007-02-09, Scott M. <s-***@nospam.nospamwrote:

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.

So can a class.

--
Tom Shelton

[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.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:9P******************************@comcast.com. ..

On 2007-02-09, Scott M. <s-***@nospam.nospamwrote:

>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.

So can a class.

--
Tom Shelton

[Tom Shelton]

On 2007-02-10, Scott M. <s-***@nospam.nospamwrote:

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.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:9P******************************@comcast.com. ..

>On 2007-02-09, Scott M. <s-***@nospam.nospamwrote:

>>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.

So can a class.

--
Tom Shelton

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).

--
Tom Shelton

[aaron.kempf]

yeah but you can't REUSE a function within a class

I mean seriously here classes are for retards and MS YESMEN.

everyone agrees that they MAKE CODE RUN SLOWER.
it is really really really really really simple.

Performance wins every debate; end of story.

-Aaron

[aaron.kempf]

you so called VB 2005 forms suck a mother fucking dick, bro

Access Data Projects work well enough; I am sick and tired of
Microsoft _NOT_FIXING_BUGS_ and still trying to sell us on a new
version.

FUCK THE BUSINESS MODEL.

-Aaron

[Tom Leylan]

I'll bet the transition from the "here is what I like" type of discussion to
one based upon actual issues will be difficult but let's try :-)

Scott wrote"you'd be doing extra work..." so the next logical question is,
what extra work? I've always used an application class to start the apps so
how much extra work have I been creating for myself? Then Tom S. suggests
that VB 2005 apps probably start with forms.

What I'm asking each person to consider is... perhaps the type of apps you
write are different (maybe the most common) but still not the only type.
There are business app, there are utilities, there are "kiosks" and there
are services. Some have no front-end, some minimal and some only need
console-based front-ends. Some (think ATM machine) typically have no menu,
and few, if any pop-up forms. Some apps are used in-house only, some are
intended for distribution and of those some to closely controlled clients
and some sold as products to the general public.

From another direction, some (and I suspect many here) are single-person
projects but that isn't too common in the business software world.
Team-based development isn't filled with "here is what I like" type
decisions or when they are the resulting app is a mess. A project estimated
to take 10 developers one year to complete isn't impacted by the "extra
work" if that means 1 minute to create a Sub Main in a class.

Programmers in typical business settings aren't (necessarily) VB experts and
it is my preference (even when the project is being written in VB) that they
are not . This has nothing to do with VB but rather a lot to do with any
self-professed language "expert." Recall the quote: "To the man with a
hammer everything looks like a nail." We've all met Access, FoxPro, VB,
Java and other language developers explaining how they could have written
the same app in half an hour and there would be no bugs. It isn't true, it
did have bugs and the apps often looked crude. They often don't aid the
user in doing their job but rather restrict the user making it harder for
them to do their job.

My point is that a style of development, the adoption of some rule, the
choice of using modules, the use of public variables, the calling of
framework methods rather than relying on VB functions, etc. is impacted by
all of the above. If a company somewhere is having a hard time
transitioning a VB6 app to .Net (assuming that is a goal) it can be in large
part because they wrote a "VB6 app" rather than an application using VB6.
Using every VB6 trick in the book can lock them into a system that is hard
to transition when no other language has whatever VB6-isms they are using.
I'm not suggesting this is a VB-only problem, the tighter the connection to
any single language the harder it will be to migrate and business needs may
dictate a migration.

So when people write "here is what I do" it might help if the person
considering it ask themself, is my situation similar? Am I writing a
similar type app, under similar conditions and intended for a similar
audience? Just because somebody writes "that's what they do at Citibank"
doesn't it make it right for you, unless perhaps you too are a large bank.
What works for your home-use contact manager program isn't likely to work
for the FDIC or NASA or on the floor of the NYSE.

Anyway that's my 2 cents (or was that 5 cents?)
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:Ua******************************@comcast.com. ..

On 2007-02-10, Scott M. <s-***@nospam.nospamwrote:

>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.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:9P******************************@comcast.com ...

>>On 2007-02-09, Scott M. <s-***@nospam.nospamwrote:
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.

So can a class.

--
Tom Shelton

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).

--
Tom Shelton

[Scott M.]

But don't forget that not all apps are Windows Forms apps. Console apps can
benefit greatly from sub main.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:Ua******************************@comcast.com. ..

On 2007-02-10, Scott M. <s-***@nospam.nospamwrote:

>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.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:9P******************************@comcast.com ...

>>On 2007-02-09, Scott M. <s-***@nospam.nospamwrote:
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.

So can a class.

--
Tom Shelton

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).

--
Tom Shelton

[aaron.kempf]

extra work?

with a class?

IT IS UNNECESSARY
SHIT RUNS FASTER WITHOUT CLASSES

[Zytan]

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

Classes allow code reuse by means of creating DLLs. Not the prettiest
things in the world, but they do work. How do modules improve on
this? I am not suggestion modules are worse -- I really don't know
the answer. So, how are modules any better? If they allow reuse in a
better way, then I may consider using them.

Although, i still haven't heard anyone upset over the fact that
modules just place everything in the global namespace. I guess you
could put the module itself in its own namespace, then you'd have to
access it through this namespace (i.e. Math.PI rather than just Pi).
Is this possible? It must be, but I've never tried it in VB.

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

Name calling doesn't help resolve the issue.

I believe most VB6 developers never wrote a class when modules exist.
But, it doesn't mean classes may not be better. Are you speaking from
experience on which is better?

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

Well, to merge all the languages together and make them more
compatible, everything runs on top of the .NET framework, and well...
it's all OOP based. To have VB .NET without classes... would be
impossible. Its run on top of an OOP framework.

Zytan

[RobinS]

Why don't you post some code samples that show the same thing running in
VB6 and VB2005 and show the performance statistics?

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------
<aa*********@gmail.comwrote in message
news:11*********************@a34g2000cwb.googlegro ups.com...

extra work?

with a class?

IT IS UNNECESSARY
SHIT RUNS FASTER WITHOUT CLASSES

[RobinS]

<aa*********@gmail.comwrote in message
news:11*********************@k78g2000cwa.googlegro ups.com...

yeah but you can't REUSE a function within a class

I mean seriously here classes are for retards and MS YESMEN.

everyone agrees that they MAKE CODE RUN SLOWER.
it is really really really really really simple.

Performance wins every debate; end of story.

-Aaron

Yes, you *can* reuse a function within a class.

Again, why don't you create a small project in VB6 and in VB2005 and show
the performance statistics?
Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------

[Zytan]

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

>
it's called CODE REUSE

Classes offer the same thing.

Methods have to offer something MORE than a class to make it MORE
useful than a class. A few here have shown where a method may be more
desirable, but still, i haven't heard a reason why you want to clutter
to the global namespace, when a class doesn't do this.

not everything fits into a class

I agree a set of functions that need never be instantiated are better
in a method. I just don't like that they all become global. If it
were not for that, I think a method is far better for such things.
Not everything need be in a class, i agree.

Zytan

[Zytan]

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.

Agreed. Thanks for your input.

Zytan.

[Zytan]

extra work?

>
with a class?

IT IS UNNECESSARY
SHIT RUNS FASTER WITHOUT CLASSES

Not necessarily. The common belief that classes add extra overhead is
unfounded almost all of the time.

Also, do methods provide encapsulation like classes do? I really
don't know...

Zytan

[Tom Shelton]

On 2007-02-10, Scott M. <s-***@nospam.nospamwrote:

But don't forget that not all apps are Windows Forms apps. Console apps can
benefit greatly from sub main.

Yes - all .net apps have a sub main even if you don't see it. And, if I was
writing a console app, that sub main would exist in a class.

--
Tom Shelton

[Tom Shelton]

On 2007-02-10, Tom Leylan <tl*****@nospam.netwrote:

I'll bet the transition from the "here is what I like" type of discussion to
one based upon actual issues will be difficult but let's try :-)

Scott wrote"you'd be doing extra work..." so the next logical question is,
what extra work? I've always used an application class to start the apps so
how much extra work have I been creating for myself? Then Tom S. suggests
that VB 2005 apps probably start with forms.

Only win forms apps - and like I said they don't have to, it's just that
VB2005 provides a lot of functionality if you use the application framework
and that requires your startup object be a form.

--
Tom Shelton

[Tom Leylan]

Scott: Rather than just say "can benefit greatly" try to list one item, two
or three if there are than many benefits. I personally know of no benefit
so if you posted one it would help me and I'm sure others. What don't we
understand about this?
"Scott M." <s-***@nospam.nospamwrote in message
news:O7**************@TK2MSFTNGP02.phx.gbl...

But don't forget that not all apps are Windows Forms apps. Console apps
can benefit greatly from sub main.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:Ua******************************@comcast.com. ..

>On 2007-02-10, Scott M. <s-***@nospam.nospamwrote:

>>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.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:9P******************************@comcast.co m...
On 2007-02-09, Scott M. <s-***@nospam.nospamwrote:
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.

So can a class.

--
Tom Shelton

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).

--
Tom Shelton

[Cor Ligthert [MVP]]

Tom,

Nice written however I would add one consideration.

When people write "here is what I do" is in fact given an alternative for
what can be done and not telling that another should do that.

For the rest I think I agree with what you wrote. .

Cor

"Tom Leylan" <tl*****@nospam.netschreef in bericht
news:%2******************@TK2MSFTNGP05.phx.gbl...

I'll bet the transition from the "here is what I like" type of discussion
to one based upon actual issues will be difficult but let's try :-)

Scott wrote"you'd be doing extra work..." so the next logical question is,
what extra work? I've always used an application class to start the apps
so how much extra work have I been creating for myself? Then Tom S.
suggests that VB 2005 apps probably start with forms.

What I'm asking each person to consider is... perhaps the type of apps you
write are different (maybe the most common) but still not the only type.
There are business app, there are utilities, there are "kiosks" and there
are services. Some have no front-end, some minimal and some only need
console-based front-ends. Some (think ATM machine) typically have no
menu, and few, if any pop-up forms. Some apps are used in-house only,
some are intended for distribution and of those some to closely controlled
clients and some sold as products to the general public.

From another direction, some (and I suspect many here) are single-person
projects but that isn't too common in the business software world.
Team-based development isn't filled with "here is what I like" type
decisions or when they are the resulting app is a mess. A project
estimated to take 10 developers one year to complete isn't impacted by the
"extra work" if that means 1 minute to create a Sub Main in a class.

Programmers in typical business settings aren't (necessarily) VB experts
and it is my preference (even when the project is being written in VB)
that they are not . This has nothing to do with VB but rather a lot to do
with any self-professed language "expert." Recall the quote: "To the man
with a hammer everything looks like a nail." We've all met Access,
FoxPro, VB, Java and other language developers explaining how they could
have written the same app in half an hour and there would be no bugs. It
isn't true, it did have bugs and the apps often looked crude. They often
don't aid the user in doing their job but rather restrict the user making
it harder for them to do their job.

My point is that a style of development, the adoption of some rule, the
choice of using modules, the use of public variables, the calling of
framework methods rather than relying on VB functions, etc. is impacted by
all of the above. If a company somewhere is having a hard time
transitioning a VB6 app to .Net (assuming that is a goal) it can be in
large part because they wrote a "VB6 app" rather than an application using
VB6. Using every VB6 trick in the book can lock them into a system that is
hard to transition when no other language has whatever VB6-isms they are
using. I'm not suggesting this is a VB-only problem, the tighter the
connection to any single language the harder it will be to migrate and
business needs may dictate a migration.

So when people write "here is what I do" it might help if the person
considering it ask themself, is my situation similar? Am I writing a
similar type app, under similar conditions and intended for a similar
audience? Just because somebody writes "that's what they do at Citibank"
doesn't it make it right for you, unless perhaps you too are a large bank.
What works for your home-use contact manager program isn't likely to work
for the FDIC or NASA or on the floor of the NYSE.

Anyway that's my 2 cents (or was that 5 cents?)
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:Ua******************************@comcast.com. ..

>On 2007-02-10, Scott M. <s-***@nospam.nospamwrote:

>>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.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:9P******************************@comcast.co m...
On 2007-02-09, Scott M. <s-***@nospam.nospamwrote:
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.

So can a class.

--
Tom Shelton

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).

--
Tom Shelton

[Cor Ligthert [MVP]]

Tom,

In my opinin it is easier, all programs need from the first day the computer
exist a fixed starting point. That was without an OS always 000000. That we
call that now sub main is only for humans in my idea.

Cor

"Tom Shelton" <to*********@comcastXXXXXXX.netschreef in bericht
news:q-******************************@comcast.com...

On 2007-02-10, Scott M. <s-***@nospam.nospamwrote:

>But don't forget that not all apps are Windows Forms apps. Console apps
can
benefit greatly from sub main.

Yes - all .net apps have a sub main even if you don't see it. And, if I
was
writing a console app, that sub main would exist in a class.

--
Tom Shelton

[Cor Ligthert [MVP]]

Tom,

I still don't understand your preference, see this shared class and the
module.

Public Class TheClass
Private Shared mymember As Integer
Friend Shared Property Member() As Integer
Get
Return mymember
End Get
Set(ByVal value As Integer)
mymember = value
End Set
End Property
Public Shared Sub Method()
End Sub
End Class

Public Module TheModule
Private mymember As Integer
Friend Property Member() As Integer
Get
Return mymember
End Get
Set(ByVal value As Integer)
mymember = value
End Set
End Property
Public Sub Method()
End Sub
End Module

I find the module much nicer. (For those who saw my name in this thread, I
have changed my idea about this in favour for a *good* written module. That
good is very important in that)

Cor

"Tom Leylan" <tl*****@nospam.netschreef in bericht
news:ez**************@TK2MSFTNGP04.phx.gbl...

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.

"Zytan" <zy**********@yahoo.comwrote in message
news:11**********************@k78g2000cwa.googlegr oups.com...

>>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.

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.

[Zytan]

Performance wins every debate; end of story.

Then assembly is the best language. Since when was VB for writing
fast programs? It's for rapid / ease of development. Speed is an
issue, not the primary goal.

Zytan

[Zytan]

Again, why don't you create a small project in VB6 and in VB2005 and show

the performance statistics?

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

[Bruce W. Darby]

I'll answer that for him, Robin.... because he CAN'T!! I'm coming to the
conclusion that our neophyte troll doesn't know how to program. If he can't
drag it and drop it, he's lost. Now, he COULD prove me wrong, but I doubt
that he'll even attempt to. :)

Bruce

"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:xs******************************@comcast.com. ..

Why don't you post some code samples that show the same thing running in
VB6 and VB2005 and show the performance statistics?

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------

[Bruce W. Darby]

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/d...components.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

"Zytan" <zy**********@yahoo.comwrote in message
news:11*********************@a75g2000cwd.googlegro ups.com...

>Again, why don't you create a small project in VB6 and in VB2005 and show
the performance statistics?

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

[Lloyd Sheen]

I worked on an app in VB6 and it had over 500 classes. So if whoever is
saying this can eat his words.
"Bruce W. Darby" <kr******@atcomcast.netwrote in message
news:r_******************************@comcast.com. ..

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/d...components.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

"Zytan" <zy**********@yahoo.comwrote in message
news:11*********************@a75g2000cwd.googlegro ups.com...

>>Again, why don't you create a small project in VB6 and in VB2005 and
show
the performance statistics?

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

[Tom Leylan]

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?
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

Tom,

I still don't understand your preference, see this shared class and the
module.

Public Class TheClass
Private Shared mymember As Integer
Friend Shared Property Member() As Integer
Get
Return mymember
End Get
Set(ByVal value As Integer)
mymember = value
End Set
End Property
Public Shared Sub Method()
End Sub
End Class

Public Module TheModule
Private mymember As Integer
Friend Property Member() As Integer
Get
Return mymember
End Get
Set(ByVal value As Integer)
mymember = value
End Set
End Property
Public Sub Method()
End Sub
End Module

I find the module much nicer. (For those who saw my name in this thread, I
have changed my idea about this in favour for a *good* written module.
That good is very important in that)

Cor

"Tom Leylan" <tl*****@nospam.netschreef in bericht
news:ez**************@TK2MSFTNGP04.phx.gbl...

>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.

"Zytan" <zy**********@yahoo.comwrote in message
news:11**********************@k78g2000cwa.googleg roups.com...

>>>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.

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.

[Tom Leylan]

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.
"Zytan" <zy**********@yahoo.comwrote in message
news:11*********************@a75g2000cwd.googlegro ups.com...

>Again, why don't you create a small project in VB6 and in VB2005 and show
the performance statistics?

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

[Scott M.]

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.


"Tom Leylan" <tl*****@nospam.netwrote in message
news:%2******************@TK2MSFTNGP05.phx.gbl...

I'll bet the transition from the "here is what I like" type of discussion
to one based upon actual issues will be difficult but let's try :-)

Scott wrote"you'd be doing extra work..." so the next logical question is,
what extra work? I've always used an application class to start the apps
so how much extra work have I been creating for myself? Then Tom S.
suggests that VB 2005 apps probably start with forms.

What I'm asking each person to consider is... perhaps the type of apps you
write are different (maybe the most common) but still not the only type.
There are business app, there are utilities, there are "kiosks" and there
are services. Some have no front-end, some minimal and some only need
console-based front-ends. Some (think ATM machine) typically have no
menu, and few, if any pop-up forms. Some apps are used in-house only,
some are intended for distribution and of those some to closely controlled
clients and some sold as products to the general public.

From another direction, some (and I suspect many here) are single-person
projects but that isn't too common in the business software world.
Team-based development isn't filled with "here is what I like" type
decisions or when they are the resulting app is a mess. A project
estimated to take 10 developers one year to complete isn't impacted by the
"extra work" if that means 1 minute to create a Sub Main in a class.

Programmers in typical business settings aren't (necessarily) VB experts
and it is my preference (even when the project is being written in VB)
that they are not . This has nothing to do with VB but rather a lot to do
with any self-professed language "expert." Recall the quote: "To the man
with a hammer everything looks like a nail." We've all met Access,
FoxPro, VB, Java and other language developers explaining how they could
have written the same app in half an hour and there would be no bugs. It
isn't true, it did have bugs and the apps often looked crude. They often
don't aid the user in doing their job but rather restrict the user making
it harder for them to do their job.

My point is that a style of development, the adoption of some rule, the
choice of using modules, the use of public variables, the calling of
framework methods rather than relying on VB functions, etc. is impacted by
all of the above. If a company somewhere is having a hard time
transitioning a VB6 app to .Net (assuming that is a goal) it can be in
large part because they wrote a "VB6 app" rather than an application using
VB6. Using every VB6 trick in the book can lock them into a system that is
hard to transition when no other language has whatever VB6-isms they are
using. I'm not suggesting this is a VB-only problem, the tighter the
connection to any single language the harder it will be to migrate and
business needs may dictate a migration.

So when people write "here is what I do" it might help if the person
considering it ask themself, is my situation similar? Am I writing a
similar type app, under similar conditions and intended for a similar
audience? Just because somebody writes "that's what they do at Citibank"
doesn't it make it right for you, unless perhaps you too are a large bank.
What works for your home-use contact manager program isn't likely to work
for the FDIC or NASA or on the floor of the NYSE.

Anyway that's my 2 cents (or was that 5 cents?)
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:Ua******************************@comcast.com. ..

>On 2007-02-10, Scott M. <s-***@nospam.nospamwrote:

>>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.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:9P******************************@comcast.co m...
On 2007-02-09, Scott M. <s-***@nospam.nospamwrote:
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.

So can a class.

--
Tom Shelton

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).

--
Tom Shelton

[Scott M.]

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.
"Tom Leylan" <tl*****@nospam.netwrote in message
news:e4*************@TK2MSFTNGP06.phx.gbl...

Scott: Rather than just say "can benefit greatly" try to list one item,
two or three if there are than many benefits. I personally know of no
benefit so if you posted one it would help me and I'm sure others. What
don't we understand about this?
"Scott M." <s-***@nospam.nospamwrote in message
news:O7**************@TK2MSFTNGP02.phx.gbl...

>But don't forget that not all apps are Windows Forms apps. Console apps
can benefit greatly from sub main.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:Ua******************************@comcast.com ...

>>On 2007-02-10, Scott M. <s-***@nospam.nospamwrote:
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.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:9P******************************@comcast.c om...
On 2007-02-09, Scott M. <s-***@nospam.nospamwrote:
>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.
>
So can a class.
>
--
Tom Shelton

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).

--
Tom Shelton

[Scott M.]

Hmmm, why don't I see Robin's message in this thread?
"Bruce W. Darby" <kr******@atcomcast.netwrote in message
news:VP******************************@comcast.com. ..

I'll answer that for him, Robin.... because he CAN'T!! I'm coming to the
conclusion that our neophyte troll doesn't know how to program. If he
can't drag it and drop it, he's lost. Now, he COULD prove me wrong, but I
doubt that he'll even attempt to. :)

Bruce

"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:xs******************************@comcast.com. ..

>Why don't you post some code samples that show the same thing running in
VB6 and VB2005 and show the performance statistics?

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------

[Scott M.]

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.

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.

>
Zytan

[Bruce W. Darby]

Not sure Scott. Are you seeing other posts by Robin? Or did you
inadvertently add him to your killfile?

"Scott M." <s-***@nospam.nospamwrote in message
news:Oe**************@TK2MSFTNGP06.phx.gbl...

Hmmm, why don't I see Robin's message in this thread?
"Bruce W. Darby" <kr******@atcomcast.netwrote in message
news:VP******************************@comcast.com. ..

>I'll answer that for him, Robin.... because he CAN'T!! I'm coming to the
conclusion that our neophyte troll doesn't know how to program. If he
can't drag it and drop it, he's lost. Now, he COULD prove me wrong, but I
doubt that he'll even attempt to. :)

Bruce

"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:xs******************************@comcast.com ...

>>Why don't you post some code samples that show the same thing running in
VB6 and VB2005 and show the performance statistics?

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------

[Tom Leylan]

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 M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

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.


"Tom Leylan" <tl*****@nospam.netwrote in message
news:%2******************@TK2MSFTNGP05.phx.gbl...

>I'll bet the transition from the "here is what I like" type of discussion
to one based upon actual issues will be difficult but let's try :-)

Scott wrote"you'd be doing extra work..." so the next logical question
is, what extra work? I've always used an application class to start the
apps so how much extra work have I been creating for myself? Then Tom S.
suggests that VB 2005 apps probably start with forms.

What I'm asking each person to consider is... perhaps the type of apps
you write are different (maybe the most common) but still not the only
type. There are business app, there are utilities, there are "kiosks" and
there are services. Some have no front-end, some minimal and some only
need console-based front-ends. Some (think ATM machine) typically have
no menu, and few, if any pop-up forms. Some apps are used in-house only,
some are intended for distribution and of those some to closely
controlled clients and some sold as products to the general public.

From another direction, some (and I suspect many here) are single-person
projects but that isn't too common in the business software world.
Team-based development isn't filled with "here is what I like" type
decisions or when they are the resulting app is a mess. A project
estimated to take 10 developers one year to complete isn't impacted by
the "extra work" if that means 1 minute to create a Sub Main in a class.

Programmers in typical business settings aren't (necessarily) VB experts
and it is my preference (even when the project is being written in VB)
that they are not . This has nothing to do with VB but rather a lot to
do with any self-professed language "expert." Recall the quote: "To the
man with a hammer everything looks like a nail." We've all met Access,
FoxPro, VB, Java and other language developers explaining how they could
have written the same app in half an hour and there would be no bugs. It
isn't true, it did have bugs and the apps often looked crude. They often
don't aid the user in doing their job but rather restrict the user making
it harder for them to do their job.

My point is that a style of development, the adoption of some rule, the
choice of using modules, the use of public variables, the calling of
framework methods rather than relying on VB functions, etc. is impacted
by all of the above. If a company somewhere is having a hard time
transitioning a VB6 app to .Net (assuming that is a goal) it can be in
large part because they wrote a "VB6 app" rather than an application
using VB6. Using every VB6 trick in the book can lock them into a system
that is hard to transition when no other language has whatever VB6-isms
they are using. I'm not suggesting this is a VB-only problem, the tighter
the connection to any single language the harder it will be to migrate
and business needs may dictate a migration.

So when people write "here is what I do" it might help if the person
considering it ask themself, is my situation similar? Am I writing a
similar type app, under similar conditions and intended for a similar
audience? Just because somebody writes "that's what they do at Citibank"
doesn't it make it right for you, unless perhaps you too are a large
bank. What works for your home-use contact manager program isn't likely
to work for the FDIC or NASA or on the floor of the NYSE.

Anyway that's my 2 cents (or was that 5 cents?)
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:Ua******************************@comcast.com ...

>>On 2007-02-10, Scott M. <s-***@nospam.nospamwrote:
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.
"Tom Shelton" <to*********@comcastXXXXXXX.netwrote in message
news:9P******************************@comcast.c om...
On 2007-02-09, Scott M. <s-***@nospam.nospamwrote:
>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.
>
So can a class.
>
--
Tom Shelton

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).

--
Tom Shelton