Classes vs. Modules

[aaron.kempf@gmail.com]

Re: Classes vs. Modules

neither is worse than the other?

classes are more verbose, slower performance and no tangible benefit



On Feb 13, 5:16 am, "Zytan" <zytanlith...@y ahoo.comwrote:

You're no more likely to have dependencies with a class then you are
with a module. You can have a module that relies on functions in
another module, just as you can have a class that relies on functions
in another class. Both create cause your code to be tightly coupled,
and that should be avoided as much as possible, whether you use classes
or modules.

>
Yes, very true. I guess that's what I was trying to say, is that
neither is worse than the other. But, yeah, the way my post came out
was ridiculous. Thanks for clarifying.
>
Zytan

[aaron.kempf@gmail.com]

Re: Classes vs. Modules

my so called 'module encapsulation' supports code reuse
it supports private variables, it supports public variables.

I could give a shit about your premise--- that global vars are bad.

global vars are NECESSARY and HELPFUL and possibly a last resort-- but
infinitely more powerful than NOT BEING ABLE TO USE GLOBAL VARS

it's like a parachute.. if you could wear a parachute every time you
took an airline flight-- sure it might be necessary; sure it might be
a pain in the ass; sure other people might laugh at you

but what happens the one time that your airplane door gets blown off
but what happens the one time that your airplane roof gets blown off

and you're the only one with a parachute because these people said
'parachutes are frowned upon'

I don't agree with the blanket statement that global vars are evil.
global vars save a lot of effort for a lot of reasons.

and you class fags dont have the option so STFU and don't bitch about
my parachute

in some cases; it saves a lot of effort and i'm sorry that your
computer science professor was egocentric-- but he was WRONG

C++ _LOST_ the war, VB _WON_ the war
and then MS threw the game because MS; the steward of the VB family--
screwed us all by inventing visual fred


On Feb 12, 6:48 pm, "Zytan" <zytanlith...@y ahoo.comwrote:

yeah

>

module aaron

>

module matt

>

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

>
I want to reply to this again. What I meant more for encapsulation is
that because they are available globally, it means data members within
them are global. This is not proper encapsulation. Yes, what you say
above is true, but it doesn't encapsulate everything. Global vars are
horrible.
>
Zytan

[aaron.kempf@gmail.com]

Re: Classes vs. Modules

who gives a crap?

it is slower; when the single argument that they had is that it made
things faster.

DOTNET LOSES AGAIN



On Feb 12, 6:43 pm, "Zytan" <zytanlith...@y ahoo.comwrote:

I don't need to

>

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

>

it's obvious to me which is faster

>
Might that be due to the .NET framework? I would imagine in 5 years
or whatever it uses more resources than whatever VB6 uses.
>
Zytan

[Martin H.]

Re: Classes vs. Modules

Hello Aaron,

having a car class and a bicycle class and both of them have a weight
function.. so I've got to reuse some code but I CANT I need to copy
and paste the code in order to make my maintenance job harder.
>
RIGHT?

Wrong. You don't have to copy and paste, that's the good thing of it.
You just inherit and it is just there.

Example:

'The class definitions - just for reference
Public Class Vehicle
Private vWheels As Integer = 0
Public Property Wheels() As Integer
Get
Return vWheels
End Get
Set (ByVal Value As Integer)
If Value<0 Then
Err.Raise(450)
Else
vWheels = Value
End If
End Set
End Property
End Class

Public Class VehicleWithEngi ne
Inherits Vehicle
Private vHorsePower As Integer = 1
Private vCylinders As Integer = 1
Public Property HorsePower () As Integer
Get
Return vHorsePower
End Get
Set (ByVal Value As Integer)
If Value<1 Then
Err.Raise(450)
Else
vHorsePower=Val ue
End If
End Set
End Property

Public Property Cylinders As Integers
Get
Return vCylinders
End Get
Set (ByVal Value As Integer)
If Value <1 Then
Err.Raise(450)
Else
vCylinders=Valu e
EndIf
End Set
End Property
End Class

Public Class Car
Inherits VehicleWithEngi ne
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

'End of class definitions

Private Sub ABC()
Dim v As New Vehicle
Dim vwe As New VehicleWithEngi ne
Dim c As New Car

v.Wheels = 1

vwe.Wheels = 2
vwe.HorsePower = 30
vwe.Cylinders = 1

c.Wheels = 4
c.HorsePower = 110
c.Cylinders = 4
c.Doors = 3
End Sub

As you can see from the sub ABC, all variables have the "Wheels"
property (inherited from Vehicle). In addition vwe and C have the
properties "HorsePower " and "Cylinders" (from VehicleWithEngi ne) and
only c has Doors (from Car).

How you write the data into those variables is not relevant (if you do
that from a database or a user enters it or whatsoever).

Let's say that you find a bug in one of the classes. You just have to
identify the class where the code originates in order to solve the bug
for that class all classes that inherit from it. If you copy and paste
code, then you have to search all routines which use the same code.

Class Car
sub weight
'lookup weight in the database
end sub
End Class
>
Class Bicycle
sub weight
'lookup weight in the database
end sub
>
End Class
>
and don't bitch about how I should inherit both from a common vehicle
class; because uh-- shit's too complex for one way inheritence; sorry.
it just doesn't have any benefit for me; I'd rather have a module with
weight any day of the week.

Sorry, but what's so difficult to add the Weight property to the Vehicle
class?

Public Class Vehicle
Private vWheels As Integer = 0
private vWeight As Decimal = 0
Public Property Wheels() As Integer
Get
Return vWheels
End Get
Set (ByVal Value As Integer)
If Value<0 Then
Err.Raise(450)
Else
vWheels = Value
End If
End Set
End Property

Public Property Weight() As Decimal
Get
Return vWeight
End Get
Set (ByVal Value As Decimal)
If Value<0 Then
Err.Raise(450)
Else
vWeight = Value
End If
End Set
End Property
End Class

unnecessary code maintenance is not necessary

Exactly that's where classes help you. They code becomes easier to maintain.

and how when I'm trying to explain to a C# friend why I use a module;
he's like 'uh I dont get it'

I'm also from the classic VB line and used modules a lot. Nevertheless,
the classes in VB.NET are helpful.

Best regards,

Martin

[Herfried K. Wagner [MVP]]

Re: Classes vs. Modules

"Zytan" <zytanlithium@y ahoo.comschrieb :

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

>
I've grown tired of monospaced fonts and moved to variable width
fonts, and smaller fonts, and moved all my toolbars out of the way to
essentially show line lengths 3 times or more the length they normally
would show. This helps ease the issue of readability.

I am not writing the code for myself. It needs to be readable and easily
maintainable for other people reading and extending it.

Importing everything is a huge no-no.

I do not import anything, but I import any namespaces containing types I am
using. So reading the 'Imports' section shows which namespaces are used.

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

[=?Utf-8?B?UmljaA==?=]

Re: Classes vs. Modules

With inheritance you can do stuff like this:

Dim arrtxt() As TextBox
arrtxt = New TextBox(){Text0 , Text1, Text2,...)
For Each txt As TextBox In arrtx t: AddHandler txt.Leave, AddressOf someProc
: Next

In VB6 it would be this:

Private Sub Text0_LostFocus ()
dosomething
End Sub

Private Sub Text1_LostFocus ()
DoSomething
End Sub
....

My code has shrunk nearly 30% by switching to VB2005 from VB6, plus the
VS2005 IDE catches more errors than anything I have ever seen. It is almost
impossible to write buggy code (at the compiler level) in VS2005 (VB, C#...)

As far as running slow goes, if your clients are using antiquated hardware,
then yes -- you are resigned to using antiquated technology. But if they
are using current hardware, then VS2005 will run just as fast as the old
stuff. One line of code in VB2005 packs way more punch than a line of code
in VB6, so yes, you will need a bigger engine to run it.

"aaron.kempf@gm ail.com" wrote:

>
sorry I meant multiple inheritence
>
ala C++
>
OOP without multiple inheritence is no better off than VB6
>
and OOP without design tools ala class designer is a joke
it shouldn't cost 3 grand if 'everyone should be using classes for
everything'
>
I just do not see any new functionality that classes give me; and I've
got a dozen books that state that they give slower execution time.
so only a bastard would subject their clients to slower execution
time.
>
seriously-- performance is king; oop does not help performance; it
hurts it; so i'll continue with my procedural / spaghetti code thank
you very much
>
>
>
>
On Feb 12, 10:44 am, "Michael D. Ober" <obermd.@.alum. mit.edu.nospam>
wrote:

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

Mike Ober.

<aaron.ke...@gm ail.comwrote in message

news:1171302098 .611440.30110@p 10g2000cwp.goog legroups.com...

fully agree spam catcher

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

(since vb 2005 and c# don't support polymorphism)

On Feb 11, 12:43 am, Spam Catcher <spamhoney...@r ogers.comwrote:
>"Zytan" <zytanlith...@y ahoo.comwrote in news:1171055866 .052844.204220
>@h3g2000cwc.go oglegroups.com:

I try to avoid global vars like the plague, as do most, so I cannot
see why anyone would still want to use this.

>For redundant functions it doesn't make sent to need to instaniate
>everytime just to use em :-)

>
>
>

[Zytan]

Re: Classes vs. Modules

neither is worse than the other?

>
classes are more verbose, slower performance and no tangible benefit

We were talking about dependencies. I will not discuss something I
did not say. Please keep on topic.

Zytan

[Zytan]

Re: Classes vs. Modules

zytan

>
is not your method more verbose?

Yes.

And it's more accurate.

This helps for people that are new to the framework. As I get used to
it, I'll stop being verbose. The verbose-ness is not that bad using
intellisense, since the amount of typing is very little. Yes, not as
minimal as without all the explicit typing, but much more minimal that
people first realize. It hardly slows me down. And when it does, it
helps me learn. So, it's ok, for now.

Zytan

[Zytan]

Re: Classes vs. Modules

I've grown tired of monospaced fonts and moved to variable width

fonts, and smaller fonts, and moved all my toolbars out of the way to
essentially show line lengths 3 times or more the length they normally
would show. This helps ease the issue of readability.

>
I am not writing the code for myself. It needs to be readable and easily
maintainable for other people reading and extending it.

Good point.

Importing everything is a huge no-no.

>
I do not import anything, but I import any namespaces containing types I am
using. So reading the 'Imports' section shows which namespaces are used.

(Just to be clear, I said 'no-no' for beginners trying to learn the
framework, not seasoned experts.)

Yes, understood. It shouldn't be so bad if it is just for types. A
few of these things are imported by default, anyway.

Zytan

[Zytan]

Re: Classes vs. Modules

it is slower; when the single argument that they had is that it made

things faster.

I think they meant development time.

Go program a winsock VB6 app and compare it to my VB .NET.

See you next year.

Zytan

[Zytan]

Re: Classes vs. Modules

modules support code reuse, classes do not

Now that's just silly.

Zytan

[Scott M.]

Re: Classes vs. Modules

>Importing everything is a huge no-no.

Not sure if you originally said this Zytan, but whoever did, that's just
plain wrong.

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

[Tom Shelton]

Re: Classes vs. Modules

On Feb 13, 10:23 am, "aaron.ke...@gm ail.com" <aaron.ke...@gm ail.com>
wrote:

tom
>
well you can either duplicate your code in multiple classes
or make a functions class and instantiate the class before using the
methods within another class right?
>
either way you got dependencies and no benefit
>

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:

module ExampleModule
public sub DoCoolStuff ()
' do cool stuff
end sub
end module

and

class ExampleClass
private sub New ()
end sub

public shared sub DoCoolStuff()
' do cool stuff
end sub
end class

are functionaly equivalent. You do not need to instantiate
ExampleClass to call DoCoolStuff. You call it like:

ExampleClass.Do CoollStuff()

Dependencies are not an issue unless you code them to be an issue -
and the same applies to modules. Also, in these cases, there really
isn't going to be a performance difference - ExampleModule is
essentially going to turn into ExampleClass at compile time.

You also seem to be under the false impression that instantiating a
class multple times results in duplication of the code of that class
in memory.... It does not. All isntances share the same code. All
instance methods take a hidden pointer to the current instance (this
is generated by the compiler). So, if for example DoCoolStuff was not
declared as shared in ExampleClass, then what you would end up at
compile time would essentially be something looked like:

Sub DoCoolStuff (ByVal Me As ExampleClass)

HTH

--
Tom Shelton

[aaron.kempf@gmail.com]

Re: Classes vs. Modules

no DUDE you are wrong

I can inherit in ONE DIRECTION

but what about when I have a house and a car that has a DOOR? then I
need to copy and paste

duplicate code is not efficient; sorry classes are for fags

On Feb 13, 9:42 am, "Martin H." <h...@gmx.netwr ote:

Hello Aaron,
>

having a car class and a bicycle class and both of them have a weight
function.. so I've got to reuse some code but I CANT I need to copy
and paste the code in order to make my maintenance job harder.

>

RIGHT?

>
Wrong. You don't have to copy and paste, that's the good thing of it.
You just inherit and it is just there.
>
Example:
>
'The class definitions - just for reference
Public Class Vehicle
Private vWheels As Integer = 0
Public Property Wheels() As Integer
Get
Return vWheels
End Get
Set (ByVal Value As Integer)
If Value<0 Then
Err.Raise(450)
Else
vWheels = Value
End If
End Set
End Property
End Class
>
Public Class VehicleWithEngi ne
Inherits Vehicle
Private vHorsePower As Integer = 1
Private vCylinders As Integer = 1
Public Property HorsePower () As Integer
Get
Return vHorsePower
End Get
Set (ByVal Value As Integer)
If Value<1 Then
Err.Raise(450)
Else
vHorsePower=Val ue
End If
End Set
End Property
>
Public Property Cylinders As Integers
Get
Return vCylinders
End Get
Set (ByVal Value As Integer)
If Value <1 Then
Err.Raise(450)
Else
vCylinders=Valu e
EndIf
End Set
End Property
End Class
>
Public Class Car
Inherits VehicleWithEngi ne
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
>
'End of class definitions
>
Private Sub ABC()
Dim v As New Vehicle
Dim vwe As New VehicleWithEngi ne
Dim c As New Car
>
v.Wheels = 1
>
vwe.Wheels = 2
vwe.HorsePower = 30
vwe.Cylinders = 1
>
c.Wheels = 4
c.HorsePower = 110
c.Cylinders = 4
c.Doors = 3
End Sub
>
As you can see from the sub ABC, all variables have the "Wheels"
property (inherited from Vehicle). In addition vwe and C have the
properties "HorsePower " and "Cylinders" (from VehicleWithEngi ne) and
only c has Doors (from Car).
>
How you write the data into those variables is not relevant (if you do
that from a database or a user enters it or whatsoever).
>
Let's say that you find a bug in one of the classes. You just have to
identify the class where the code originates in order to solve the bug
for that class all classes that inherit from it. If you copy and paste
code, then you have to search all routines which use the same code.
>
>
>
>
>

Class Car
sub weight
'lookup weight in the database
end sub
End Class

>

Class Bicycle
sub weight
'lookup weight in the database
end sub

>

End Class

>

and don't bitch about how I should inherit both from a common vehicle
class; because uh-- shit's too complex for one way inheritence; sorry.
it just doesn't have any benefit for me; I'd rather have a module with
weight any day of the week.

>
Sorry, but what's so difficult to add the Weight property to the Vehicle
class?
>
Public Class Vehicle
Private vWheels As Integer = 0
private vWeight As Decimal = 0
Public Property Wheels() As Integer
Get
Return vWheels
End Get
Set (ByVal Value As Integer)
If Value<0 Then
Err.Raise(450)
Else
vWheels = Value
End If
End Set
End Property
>
Public Property Weight() As Decimal
Get
Return vWeight
End Get
Set (ByVal Value As Decimal)
If Value<0 Then
Err.Raise(450)
Else
vWeight = Value
End If
End Set
End Property
End Class
>

unnecessary code maintenance is not necessary

>
Exactly that's where classes help you. They code becomes easier to maintain.
>

and how when I'm trying to explain to a C# friend why I use a module;
he's like 'uh I dont get it'

>
I'm also from the classic VB line and used modules a lot. Nevertheless,
the classes in VB.NET are helpful.
>
Best regards,
>
Martin- Hide quoted text -
>
- Show quoted text -

[aaron.kempf@gmail.com]

Re: Classes vs. Modules

ok.

here you go.

I have a text 'parser' class and then I inherit that into 15 other
classes

strainer
sifter
shovel
magnet

etc

yeah; i can have _SOME_ common methods.. it is _SOMEWHAT_ nice.
but it doesn't go far enough; it doesn't help me to reuse code in 15
different classes.

I wish I had my laptop here to show you my real examples.



using classes is totally inefficient; I've got a dozen MS press books
that admit that using classes is slower-- if you want to send me new
copies of these books that are corrected; I would be glad to change my
opinion.

But MS doesn't fix bugs; all those dipshits do is run around like a
bunch of retards; trying to sell us on new version

and I understand the perils of maintaing code in multiple places.

THAT IS WHY I DO NOT USE CLASSES.

my apps run faster than yours, classes do not give me any new
functionality

I don't see the point in newbies giving a crap about classes; sorry.

but performance trumps everything else.
and classes are on the losing side.

they are MORE VERBOSE and SLOWER.

end of story



On Feb 13, 9:42 am, "Martin H." <h...@gmx.netwr ote:

Hello Aaron,
>

having a car class and a bicycle class and both of them have a weight
function.. so I've got to reuse some code but I CANT I need to copy
and paste the code in order to make my maintenance job harder.

>

RIGHT?

>
Wrong. You don't have to copy and paste, that's the good thing of it.
You just inherit and it is just there.
>
Example:
>
'The class definitions - just for reference
Public Class Vehicle
Private vWheels As Integer = 0
Public Property Wheels() As Integer
Get
Return vWheels
End Get
Set (ByVal Value As Integer)
If Value<0 Then
Err.Raise(450)
Else
vWheels = Value
End If
End Set
End Property
End Class
>
Public Class VehicleWithEngi ne
Inherits Vehicle
Private vHorsePower As Integer = 1
Private vCylinders As Integer = 1
Public Property HorsePower () As Integer
Get
Return vHorsePower
End Get
Set (ByVal Value As Integer)
If Value<1 Then
Err.Raise(450)
Else
vHorsePower=Val ue
End If
End Set
End Property
>
Public Property Cylinders As Integers
Get
Return vCylinders
End Get
Set (ByVal Value As Integer)
If Value <1 Then
Err.Raise(450)
Else
vCylinders=Valu e
EndIf
End Set
End Property
End Class
>
Public Class Car
Inherits VehicleWithEngi ne
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
>
'End of class definitions
>
Private Sub ABC()
Dim v As New Vehicle
Dim vwe As New VehicleWithEngi ne
Dim c As New Car
>
v.Wheels = 1
>
vwe.Wheels = 2
vwe.HorsePower = 30
vwe.Cylinders = 1
>
c.Wheels = 4
c.HorsePower = 110
c.Cylinders = 4
c.Doors = 3
End Sub
>
As you can see from the sub ABC, all variables have the "Wheels"
property (inherited from Vehicle). In addition vwe and C have the
properties "HorsePower " and "Cylinders" (from VehicleWithEngi ne) and
only c has Doors (from Car).
>
How you write the data into those variables is not relevant (if you do
that from a database or a user enters it or whatsoever).
>
Let's say that you find a bug in one of the classes. You just have to
identify the class where the code originates in order to solve the bug
for that class all classes that inherit from it. If you copy and paste
code, then you have to search all routines which use the same code.
>
>
>
>
>

Class Car
sub weight
'lookup weight in the database
end sub
End Class

>

Class Bicycle
sub weight
'lookup weight in the database
end sub

>

End Class

>

and don't bitch about how I should inherit both from a common vehicle
class; because uh-- shit's too complex for one way inheritence; sorry.
it just doesn't have any benefit for me; I'd rather have a module with
weight any day of the week.

>
Sorry, but what's so difficult to add the Weight property to the Vehicle
class?
>
Public Class Vehicle
Private vWheels As Integer = 0
private vWeight As Decimal = 0
Public Property Wheels() As Integer
Get
Return vWheels
End Get
Set (ByVal Value As Integer)
If Value<0 Then
Err.Raise(450)
Else
vWheels = Value
End If
End Set
End Property
>
Public Property Weight() As Decimal
Get
Return vWeight
End Get
Set (ByVal Value As Decimal)
If Value<0 Then
Err.Raise(450)
Else
vWeight = Value
End If
End Set
End Property
End Class
>

unnecessary code maintenance is not necessary

>
Exactly that's where classes help you. They code becomes easier to maintain.
>

and how when I'm trying to explain to a C# friend why I use a module;
he's like 'uh I dont get it'

>
I'm also from the classic VB line and used modules a lot. Nevertheless,
the classes in VB.NET are helpful.
>
Best regards,
>
Martin- Hide quoted text -
>
- Show quoted text -