Classes vs. Modules

[Tom Leylan]

Re: Classes vs. Modules

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" <zytanlithium@y ahoo.comwrote in message
news:1171059555 .318195.200810@ k78g2000cwa.goo glegroups.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.Vis ualBasic.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@gmail.com]

Re: Classes vs. Modules

'common functions' dont belong in a class?

SO WHY USE A CLASS _EVER_?

-Aaron

[Tom Shelton]

Re: Classes vs. Modules

On 2007-02-09, Scott M. <s-mar@nospam.nosp amwrote:

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

Re: Classes vs. Modules

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" <tom_shelton@co mcastXXXXXXX.ne twrote in message
news:9PqdnSIfra 5JplDYnZ2dnUVZ_ uHinZ2d@comcast .com...

On 2007-02-09, Scott M. <s-mar@nospam.nosp amwrote:

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

Re: Classes vs. Modules

On 2007-02-10, Scott M. <s-mar@nospam.nosp amwrote:

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" <tom_shelton@co mcastXXXXXXX.ne twrote in message
news:9PqdnSIfra 5JplDYnZ2dnUVZ_ uHinZ2d@comcast .com...

>On 2007-02-09, Scott M. <s-mar@nospam.nosp amwrote:

>>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@gmail.com]

Re: Classes vs. Modules

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@gmail.com]

Re: Classes vs. Modules

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_BUG S_ and still trying to sell us on a new
version.

FUCK THE BUSINESS MODEL.

-Aaron

[Tom Leylan]

Re: Classes vs. Modules

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" <tom_shelton@co mcastXXXXXXX.ne twrote in message
news:UaqdnU71u9 Zty1DYnZ2dnUVZW hednZ2d@comcast .com...

On 2007-02-10, Scott M. <s-mar@nospam.nosp amwrote:

>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
>automaticall y with a module and Sub Main.
>>
>>
>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>news:9PqdnSIfr a5JplDYnZ2dnUVZ _uHinZ2d@comcas t.com...

>>On 2007-02-09, Scott M. <s-mar@nospam.nosp amwrote:
>>>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.]

Re: Classes vs. Modules

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


"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
news:UaqdnU71u9 Zty1DYnZ2dnUVZW hednZ2d@comcast .com...

On 2007-02-10, Scott M. <s-mar@nospam.nosp amwrote:

>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
>automaticall y with a module and Sub Main.
>>
>>
>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>news:9PqdnSIfr a5JplDYnZ2dnUVZ _uHinZ2d@comcas t.com...

>>On 2007-02-09, Scott M. <s-mar@nospam.nosp amwrote:
>>>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@gmail.com]

Re: Classes vs. Modules

extra work?

with a class?

IT IS UNNECESSARY
SHIT RUNS FASTER WITHOUT CLASSES

[Zytan]

Re: Classes vs. Modules

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]

Re: Classes vs. Modules

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.
-----------------------------------------------
<aaron.kempf@gm ail.comwrote in message
news:1171132892 .927097.96540@a 34g2000cwb.goog legroups.com...

extra work?
>
with a class?
>
IT IS UNNECESSARY
SHIT RUNS FASTER WITHOUT CLASSES
>

[RobinS]

Re: Classes vs. Modules


<aaron.kempf@gm ail.comwrote in message
news:1171131465 .878130.69930@k 78g2000cwa.goog legroups.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]

Re: Classes vs. Modules

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]

Re: Classes vs. Modules

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.