Classes vs. Modules

  • Thread starter Thread starter Zytan
  • Start date Start date
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
 
you so called VB 2005 forms suck a mother ****ing 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.

**** THE BUSINESS MODEL.

-Aaron
 
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?)
 
But don't forget that not all apps are Windows Forms apps. Console apps can
benefit greatly from sub main.
 
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 **** 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
 
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.
 
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.
-----------------------------------------------
 
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
 
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.
 
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
 
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.
 
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.
 
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?
 
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,

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,

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
 
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
 
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
 
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
 
Back
Top