Classes vs. Modules

  • Thread starter Thread starter Zytan
  • Start date Start date
Tom

sorry dog that is bad form.

using classes are more verbose and slower performance; eat a dick and
think about your customers first.

PERFORMANCE WINS EVERY ARGUMENT.
 
Tom, this one's beyond repair. You couldn't have explained it any
better. Most have already explained it, but you've gone into extreme
detail. It made me understand it better myself, actually, so thanks,
it was still useful for the rest of us.

Zytan
 
PROGRAMMING WITHOUT CLASSES IS MORE MAINTAINABLE

You can't be serious.

Implement the .NET framework without classes. See if you can maintain
it.

Zytan
 
I am sorry you admit that it is more verbose; and yet you still use
classes?
Yes.

WHAT THE HELL IS WRONG WITH YOU?

Nothing. I explained why. Read it.

For once reply to my words, my reason, instead of turning the
dicussion to all of this following crap that **I am not even involved
in**:
classes can't inherit _JACKSHIT_

sorry

but i militantly disagree with anything that is a feature in VB
DOTNET; sorry I mean VB 2005

classes make shit run slower; they involve more typing.

if you use them you are a stupid ****ing yesman, selling your soul for
the wrong causes

**** MS AND **** CLASSES

80% of Vb6 developers 'never needed a class'

UNNECESSARY CHANGE IS NOT _SEXY_

UNNECESSARY CHANGE IS NOT _HELPFUL_

UNNECESSARY CHANGE IS NOT _NECESSARY_

Why are you replying to my post with stuff you're talking to other
people about?

Zytan
 
Importing everything is a huge no-no.
Not sure if you originally said this Zytan, but whoever did, that's just
plain wrong.

I said it. It was taken out of context. That's why when I replied to
it being quoted like this, I attempted to place it back into context.
Here's the original quote:

"Right now, for me being a beginner, there's an overload of info, so
I
want to know what is where. Importing everything is a huge no-no.
Maybe it works for veterans, but for others, I can't see this helping
since they never get a feel for the framework." -- Zytan

I mean "for others" = beginners.

I hope that is clear.

Context, people, please :) It matters.

If you don't like importing everything, fine, then don't, but that doesn't
make it bad convention or a best practice not to do it.

I totally agree.

I agree 100% with Herfried on this. Import what you are using (or in the
case of C#, use "using" statements on what you are importing). Do it at the
top of the code. Unless there would be a naming collision, use the
unqualified type name.

I will once I get used to the framework more.

Zytan
 
I'll go to archive.org and type in WinsockVB.com and I'm done with the
code already kid

Then pick something you can't copy, cuz I could do the same in that
case.

Same argument applies. Next year. Have fun.

Zytan
 
please provide MS press titles and page numbers

Scott;

if you want to talk about C# you can go **** some monkeys in Africa

come talk about c# to my face, BITCH

this is a VB newsgroup; mother ****er don't even mention that
language; it was never created.

DIPSHITS SHOULD HAVE MADE VB BUGFREE BEFORE PULLING RESOURCES OFF OF
VB7.

AS IT IS; VB7 and C# have been buggy as hell; so mother ****ing take
your crap and shove it up your ass

bitch

I've got MS press books that state that classes involve more verbosity
and slower performance.

if you guys don't accept these as facts; then you can **** yourself.

if you do accept it as fact and you keep on using classes then you can
still **** yourself
 
Tom, this one's beyond repair. You couldn't have explained it any
better. Most have already explained it, but you've gone into extreme
detail. It made me understand it better myself, actually, so thanks,
it was still useful for the rest of us.

Zytan

Well, I'm glad it was helpful to someone. I am probably going to refrain from
replying to aarons nonsense from now on.
 
A module in VB.NET is a class (and AFIK, was in VB6 as well). Do you
understand the concept of a shared method? You do not have to
instantiate anything. For example:
No not that. A module cannot be instanced.

A class that is in fact a part of the memory and therefore shareble for any
other part of the program is technical not a class. This can be a module,
although a the use of a module can as well be restricted to the module only
by using private members in it.

A class should never represent a memory part or whatever. This is what the
misused name class in some programma languages (read the text from Herfried
for that), makes OOP without any reason difficult to learn for newbies and
is in my opinion only good for bookwriters/teachers.

Some people have the behaviour to follow what is told/written, not the
facts. (I can use a recent political sample, I assume that you understand
why I don't do that).


Cor
 
No not that. A module cannot be instanced.

Neither can a class with a private constructor. A module is implemented as a
class. A class with all shared members and a private constructor. The
equivalent of what in C# is now called a static class.
A class that is in fact a part of the memory and therefore shareble for any
other part of the program is technical not a class.

Why not? I use this all the time... For example, I have a ObjectManager
class that represents the interface into a buisness object layer. This is a
static class with a lot of methods like, SaveObject, CreateObject,
DeleteObject, GetObjectList, etc. (a lot of these are either generics or take
types with specific base classes or interfaces).

It makes no sense to instantiate this class - it is used everywhere. So, it
is a static class.
This can be a module,
although a the use of a module can as well be restricted to the module only
by using private members in it.

Same with a class.
A class should never represent a memory part or whatever. This is what the
misused name class in some programma languages (read the text from Herfried
for that), makes OOP without any reason difficult to learn for newbies and
is in my opinion only good for bookwriters/teachers.

I have read your's and Herfrieds comments. I respectfully disagree. I do not
think there is anything inherintly non-OOP. The concept of class methods
(shared methods in vb.net) has existed pretty much as long as OOP. I am not
advocating there use every where, but they certainly have their place. I prefer
to use a class since:

1) it makes me qualify the methods.
2) tends, in my mind, to lead to more coherent grouping of functionality
3) seems to often be closer to my intent anyway.
Some people have the behaviour to follow what is told/written, not the
facts. (I can use a recent political sample, I assume that you understand
why I don't do that).

Not everyone agrees with your position. In fact, I strongly
disagree. I'll put it this way, even though I have pretty much abandoned the
path of VB, when I do occasionlly do work with it - I NEVER USE MODULES.

I think newbies should be exposed to both sides of the coin, Cor. That's why
I like these kinds of discussions. We that are more experienced can learn from each
other, and hopefully, the newbies can get enough of both sides of the argument that they
can make up their own minds in an informed manner. Ultimately, I don't
believe that either side is correct or incorrect - it all comes down to your
own personal style :)
 
Tom,

Hitler had a National Socialistic Party.

The word Socialistic had (almost) nothing to do with his party (slightly it
has and you can even debate about it).

This is equivalent for me with the static/shared class, which is no class,
until you have a complete nation behind you which is indoctrinated.

Maybe a simpler one for those not so well informed about politics in Europe.
Because somebody calls a dog a horse, does not make that a dog is a horse
although a dog has four legs.

Cor
 
Tom

keep you and your diseased skanky ass C#, coke-snorting ass the _FUCK_
out of my newsgroup then
 
80% of VB6 programmers 'never used a class'

who decided that we 'needed to be educated'?
SERIOUSLY HERE

who decided that 80% of VB6 programmers were _WRONG_?
I WANT TO KNOW

**** you and **** your classes; end of story
I've got books from MS press that claim that they lead to 'more
verbosity' and 'slower performance'

if you choose to use classes you are doing your customers a dis-
service, yourself a dis-service
 
80% of VB6 programmers 'never used a class'

where does that number come from?

i took a poll of 27 people and 25 of them that used to use VB6 used classes
 
I have read your's and Herfrieds comments. I respectfully disagree. I do not
think there is anything inherintly non-OOP. The concept of class methods
(shared methods in vb.net) has existed pretty much as long as OOP. I am not
advocating there use every where, but they certainly have their place. I prefer
to use a class since:

1) it makes me qualify the methods.

This is the big one for me, being a beginner.
2) tends, in my mind, to lead to more coherent grouping of functionality
3) seems to often be closer to my intent anyway.
I think newbies should be exposed to both sides of the coin, Cor. That's why
I like these kinds of discussions. We that are more experienced can learn from each
other, and hopefully, the newbies can get enough of both sides of the argument that they
can make up their own minds in an informed manner. Ultimately, I don't
believe that either side is correct or incorrect - it all comes down to your
own personal style :)

This conversation helps a lot, with the exception of the troll, but
even he brings up an occasional spark of thought, and even from an
ignorant standpoint, all views are worth something. So, this is
great.

Right now, I have a class that was a module from an older piece of
source I started with. I made it into a class since I disliked that
modules are just 'there' without need of qualifying. But, now, it
really feels it should be a module. But, the fact that modules don't
need qualifiers bugs me a lot. But, this class as is doesn't feel
like it should be a class. So, i am 50/50 right now.

I think if I were using C#, i'd use a static class happily and never
think twice about it.

Zytan
 
Hello Aaron,
I can inherit in ONE DIRECTION

That's true.
but what about when I have a house and a car that has a DOOR? then I
need to copy and paste

No, you don't. Well, at least not completely.

Public Class Door()
Public Enum LockTypeConstants As Byte
NoLock = 0
KeyLock = 1
ElectronicLock = 2
End Enum

Public Enum MaterialConstants As Byte
NoMaterial = 0
Wood = 1
Metal = 2
Glass = 3
Plastic = 4
End Enum


Private vLockType As LockTypeConstants = LockTypeConstants.KeyLock
Private vMaterial As MaterialConstants = MaterialConstants.NoMaterial

Public Property LockType() As LockTypeSettings
Get
Return vLockType
End Get
Set (ByVal Value As LockTypeSetting)
vLockType = Value
End Set
End Property

Public Property Material() As MaterialConstants
Get
Return vMaterial
End Get
Set (ByVal Value As MaterialConstants)
vMaterial = Value
End Set
End Property
End Class

Public Class Car
Inherits VehicleWithEngine

Public [Door] As New Door

Private vDoors As Integer
Public Property Doors () As Integer
Get
Return vDoors
End Get
Set (ByVal Value As Integer)
If Value<1 Then
Err.Raise(450)
Else
vDoors = Value
End If
End Set
End Property
End Class


As you can see, I just made a public variable named "Door", which is of
the type Door. In the class "Car" I made this variable public. All the
properties of the class Door are available as part of this variable in
the class car.

Public Class House
Public [Door] As New Door
End Class

The house just got a door...and it's the same code I use.

Of course, I had to copy and paste - but only the Variable declaration,
not the code behind it. So it still saves you a lot of work.

Best regards,

Martin
 
Martin,

Read what you wrote

A house is not a kind of door, a car is not a kind of door.

The standard sample.
A horse and a whale are both mammals, however mammals are not pigs.

The door is a property from both classes, but normally not a fixed part in
this sample.

You have then just a base class of doors that you can use for all kind of
doors and construct those from that class. (What is the great difference
with a shared Class/ Module, their you don't have a base class of doors,
where you would have to cut and paste to get the same result)

Because a shared Class/Module is not a definition of a type, but seriously a
door.

Cor


Martin H. said:
Hello Aaron,
I can inherit in ONE DIRECTION

That's true.
but what about when I have a house and a car that has a DOOR? then I
need to copy and paste

No, you don't. Well, at least not completely.

Public Class Door()
Public Enum LockTypeConstants As Byte
NoLock = 0
KeyLock = 1
ElectronicLock = 2
End Enum

Public Enum MaterialConstants As Byte
NoMaterial = 0
Wood = 1
Metal = 2
Glass = 3
Plastic = 4
End Enum


Private vLockType As LockTypeConstants = LockTypeConstants.KeyLock
Private vMaterial As MaterialConstants = MaterialConstants.NoMaterial

Public Property LockType() As LockTypeSettings
Get
Return vLockType
End Get
Set (ByVal Value As LockTypeSetting)
vLockType = Value
End Set
End Property

Public Property Material() As MaterialConstants
Get
Return vMaterial
End Get
Set (ByVal Value As MaterialConstants)
vMaterial = Value
End Set
End Property
End Class

Public Class Car
Inherits VehicleWithEngine

Public [Door] As New Door

Private vDoors As Integer
Public Property Doors () As Integer
Get
Return vDoors
End Get
Set (ByVal Value As Integer)
If Value<1 Then
Err.Raise(450)
Else
vDoors = Value
End If
End Set
End Property
End Class


As you can see, I just made a public variable named "Door", which is of
the type Door. In the class "Car" I made this variable public. All the
properties of the class Door are available as part of this variable in the
class car.

Public Class House
Public [Door] As New Door
End Class

The house just got a door...and it's the same code I use.

Of course, I had to copy and paste - but only the Variable declaration,
not the code behind it. So it still saves you a lot of work.

Best regards,

Martin
 
Hello Cor,
Martin,

Read what you wrote


A house is not a kind of door, a car is not a kind of door.

Your mistaken. This is not what I wrote, but what Aaron wrote.
Apart from that, the sentence is correct.
In plain English he says: I have a house. I have a car. Both have doors.
In this case I have to copy and paste.

From my reply you can see how I implemented the Door class into the Car
class and into the House class.

Best regards,

Martin
 
"But, the fact that modules don't need qualifiers bugs me a lot."

But, if I'm not mistaken, you can put your module into a custom namespace
(like "Main" or "appStart", etc.) and then you'd be able to use those
qualifiers (or, my preference - - import the namespace at the top of your
code and NOT qualify it.
 
Back
Top