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

[Scott M.]

I rarely put anyone on my filter list, so if he's on it, he must be a real
winner!
"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:Ye******************************@comcast.com. ..

And I bet you miss that, don't you? ;-)

Robin S.
-----------------------------
"Scott M." <s-***@nospam.nospamwrote in message
news:eb**************@TK2MSFTNGP03.phx.gbl...

>Ah, that must be it since I don't see any messages from Aaron either.
"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:TM******************************@comcast.com ...

>>Yes, it was a response to Aaron Kempf. Otherwise, I didn't feel you guys
needed any help discussing this issue; you were doing great without my
input. ;-)

Robin S.
---------------------------
"Scott M." <s-***@nospam.nospamwrote in message
news:uW**************@TK2MSFTNGP06.phx.gbl...
I see this one. Perhaps you replied to someone that I have on my kill
list so I didn't see that branch!
"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:4M******************************@comcast.c om...
There's only been one post by me (Robin) *in* this entire thread. Do
you see this one?
>
Robin S.
----------------------
"Scott M." <s-***@nospam.nospamwrote in message
news:OA**************@TK2MSFTNGP05.phx.gbl.. .
>Must have. I don't see anything from Robin in this entire thread.
>>
>>
>"Bruce W. Darby" <kr******@atcomcast.netwrote in message
>news:e8******************************@comcast .com...
>>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******************************@comca st.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******************************@comc ast.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.
>>>>>-----------------------------------------------
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[Martin H.]

Hello Aaron,

lloyd

I just said that 80% of vb6 programmers 'never used a class'

why did we need to get enlightened?

does moving to classes make our code faster?

It might even slow down your program a bit (for the tiny moment the
class needs to be instantiated). However, classes have the advantage
that you can encapsulate your code so that only for those objects you
need it for you can use it.

The following examples are just easy ones to give you the idea.

Example 1:
Let's say you have a class tree and a class house:

Public Class Tree
Public Sub Water()
....
End Sub
Public Sub Soil()
....
End Sub
Public Sub Sunshine()
....
End Sub
End Class

Public Class House
Public Sub Wall()
....
End Sub
Public Sub Roof()
....
End Sub
Public Sub Window()
....
End Sub
Public Sub Door()
....
End Sub
End Class

As you see, these two classes have nothing in common. So, when using
these classes you don't need to worry that perhaps you have global
variable (BAD...) somewhere which is changed by one of the routines as
you would keep your variables only locally within a class.
Example 2:
Now, let's say you want to write a program about vehicles.

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 VehicleWithEngine
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=Value
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=Value
EndIf
End Set
End Property
End Class

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

The advantage here is, that you can reuse your code. You just write your
code (and error handling) once and you can use it over and over again,
because car has the complete functionality of Vehicle and VehicleWithEngine.

Let's say, you finished your "Car" class. Now, you need a "Truck" class.
Just inherit it from Car (as a truck is just a big, specialized car) and
add the missing things (e.g. loading ramp).

I don't say that classes are the best invention in the world, but they
can help you to keep your source code "tidy".

Best regards,

Martin

[Zytan]

that would sure be interesting to me

>
so I can make a class named 'aaron' and I can put functions in it..
and I can reuse those functions without instantiating a class?

I just don't like all of the dependencies between that style of
writing; it makes me sick to think about it

Dependencies are bad for sure. But, I am not sure what writing style
you are referring to that has dependencies? Using Modules? Using
Classes? The only 'dependency' I can see is that Classes are forced
to have everything Shared to act as a Module, but this is reinforced
if ever you attempt to use a function, so it's ok.

Zytan

[Zytan]

clutter the global namespace?

Yes. That's what it does.

does this make the app slower?

No. Besides, who's talking about speed? Even if speed mattered,
neither requires construction, so they are the same speed.

does it make carol in accounting enter data _FASTER_ ??

We're talking about programming, not UI. Keep on topic.

Zytan

[Zytan]

I think that simply importing a namespace into the file is evil (or

something close to it). My (personal, mind you) rule of thumb is, if I
must use Imports, then I must create an alias to it:

Imports SysThread = System.Threading
Imports SysRegex = System.Text.RegularExpression

As opposed to:

Imports System.Threading
Imports System.Text.RegularExpression

Wow! I didn't know you could do that!

Don't know if this relates to what you're talking about, and my
apologies if it drifts to OT.

No apologies needed! This is exactly what I am talking about! I
totally agree that importing namespaces is evil. I want to learn the
language properly, so it is important for me to know where things
are. I've been writing everything out explicitly. But, in doing so,
I can see why people get tired of it (although IntelliSense helps a
ton). But... your suggestion above is a very good answer to this, as
it saves typing, but requires the shorthand so that you remember where
the darn thing actually exists.

Great idea. And great concept that they implemented. thanks!

Zytan

[RobinS]

That's one word for him. Not the one I would use, though. ;-)

Robin S.
--------------------
"Scott M." <s-***@nospam.nospamwrote in message
news:ev****************@TK2MSFTNGP05.phx.gbl...

>I rarely put anyone on my filter list, so if he's on it, he must be a real
winner!
"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:Ye******************************@comcast.com. ..

>And I bet you miss that, don't you? ;-)

Robin S.
-----------------------------
"Scott M." <s-***@nospam.nospamwrote in message
news:eb**************@TK2MSFTNGP03.phx.gbl...

>>Ah, that must be it since I don't see any messages from Aaron either.
"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:TM******************************@comcast.co m...
Yes, it was a response to Aaron Kempf. Otherwise, I didn't feel you
guys needed any help discussing this issue; you were doing great
without my input. ;-)

Robin S.
---------------------------
"Scott M." <s-***@nospam.nospamwrote in message
news:uW**************@TK2MSFTNGP06.phx.gbl...
>I see this one. Perhaps you replied to someone that I have on my kill
>list so I didn't see that branch!
>
>
"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:4M******************************@comcast. com...
>There's only been one post by me (Robin) *in* this entire thread. Do
>you see this one?
>>
>Robin S.
>----------------------
>"Scott M." <s-***@nospam.nospamwrote in message
>news:OA**************@TK2MSFTNGP05.phx.gbl. ..
>>Must have. I don't see anything from Robin in this entire thread.
>>>
>>>
>>"Bruce W. Darby" <kr******@atcomcast.netwrote in message
>>news:e8******************************@comcas t.com...
>>>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******************************@comc ast.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******************************@com cast.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.
>>>>>>-----------------------------------------------
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[Zytan]

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.

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

[Zytan]

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

[Zytan]

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

Yes, right, of course. So you can reference the methods from the
module name. But you don't have to. Because you don't have to, I
don't feel like they are locked in there as they should be. But, they
are encapsulated, that's for sure.

For classes with shared functions, you don't need to instantiate them,
either, but yeah, it seems like a 'hack' to make it act like a module,
I know.

Zytan

[Zytan]

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

[Zytan]

you think that vb6 was build on a prior version of the .net runtime?

Not since I've asked the question, no.

yeah, vb6 had classes; it didn't support inheritence

Maybe that's why I thought it.

Zytan

[Tom Shelton]

On Feb 12, 7:30 pm, "Zytan" <[e-mail]:

that would sure be interesting to me

so I can make a class named 'aaron' and I can put functions in it..
and I can reuse those functions without instantiating a class?

I just don't like all of the dependencies between that style of
writing; it makes me sick to think about it

Dependencies are bad for sure. But, I am not sure what writing style
you are referring to that has dependencies? Using Modules? Using
Classes? The only 'dependency' I can see is that Classes are forced
to have everything Shared to act as a Module, but this is reinforced
if ever you attempt to use a function, so it's ok.

Zytan

Your 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, wether you use classes
or modules.

--
Tom Shelton

[Zytan]

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

[Tom Shelton]

On 2007-02-13, Zytan <zy**********@yahoo.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

Zytan,

Your post was fine. My reply was ment for Aaron - but I accidently
replied to you. Sorry.

--
Tom Shelton

[aaron.kempf]

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.

<[e-mail] in message

news:11*********************@p10g2000cwp.googlegro ups.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 <[e-mail]:

"Zytan" <[e-mail] in news:1171055866.052844.204220
@h3g2000cwc.googlegroups.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 :-)

[aaron.kempf]

martin

sorry I stopped reading when you admitted that it might slow down
execution a tiny bit.

i don't care how much a tiny bit is; you just conceded that classes
are worthless

and i don't need a cars class or a truck class
i have a database to store data

thanks kid


On Feb 12, 4:14 pm, "Martin H." <[e-mail]:

Hello Aaron,

lloyd

I just said that 80% of vb6 programmers 'never used a class'

why did we need to get enlightened?

does moving to classes make our code faster?

It might even slow down your program a bit (for the tiny moment the
class needs to be instantiated). However, classes have the advantage
that you can encapsulate your code so that only for those objects you
need it for you can use it.

The following examples are just easy ones to give you the idea.

Example 1:
Let's say you have a class tree and a class house:

Public Class Tree
Public Sub Water()
...
End Sub
Public Sub Soil()
...
End Sub
Public Sub Sunshine()
...
End Sub
End Class

Public Class House
Public Sub Wall()
...
End Sub
Public Sub Roof()
...
End Sub
Public Sub Window()
...
End Sub
Public Sub Door()
...
End Sub
End Class

As you see, these two classes have nothing in common. So, when using
these classes you don't need to worry that perhaps you have global
variable (BAD...) somewhere which is changed by one of the routines as
you would keep your variables only locally within a class.

Example 2:
Now, let's say you want to write a program about vehicles.

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 VehicleWithEngine
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=Value
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=Value
EndIf
End Set
End Property
End Class

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

The advantage here is, that you can reuse your code. You just write your
code (and error handling) once and you can use it over and over again,
because car has the complete functionality of Vehicle and VehicleWithEngine.

Let's say, you finished your "Car" class. Now, you need a "Truck" class.
Just inherit it from Car (as a truck is just a big, specialized car) and
add the missing things (e.g. loading ramp).

I don't say that classes are the best invention in the world, but they
can help you to keep your source code "tidy".

Best regards,

Martin

[aaron.kempf]

Im talking about..

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?

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.

unnecessary complexity is not necessary
unnecessary complexity is not sex
unnecessary code maintenance is not necessary
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'

so BASICALLY vb came around first; fuck anything like C# and fuck
anyone that uses it.
end of story

I do not mean 'oh, i just won't use C#'

I mean I spit on anyone that uses it.
I spit on anyone that invented this language.
and I spit on microsoft sales person for mentioning it.

C# does not exist in my opinion.

those mother fucking gooks and chinks should have doubled their effort
in VB.net instead of splitting their bets and shipping an incomplete
product and an unstable IDE.

I mean 'invent a new language'

WHY? VB ALREADY HAD THE MARKETSHARE-- WAS JAVA A THREAT BACK THEN?
NOT WHERE I AM STANDING I THOUGHT THAT FREEWARE COM+ WAS A LOT BETTER
THAN J2EE FOR EXAMPLE

Visual Studio 2005 Professional crashes on me 2 times a day.
I do not have any malware / virus; and I never have n this machine-- I
used to do security _AT_ microsoft and I know what I am doing; thank
you

On Feb 12, 6:30 pm, "Zytan" <[e-mail]:

that would sure be interesting to me

so I can make a class named 'aaron' and I can put functions in it..
and I can reuse those functions without instantiating a class?

I just don't like all of the dependencies between that style of
writing; it makes me sick to think about it

Dependencies are bad for sure. But, I am not sure what writing style
you are referring to that has dependencies? Using Modules? Using
Classes? The only 'dependency' I can see is that Classes are forced
to have everything Shared to act as a Module, but this is reinforced
if ever you attempt to use a function, so it's ok.

Zytan

[aaron.kempf]

zytan

is not your method more verbose?

what you chicken shits don't understand is that vb 2002,2003 and 2005
is 'twice as verbose' as VB6
and it runs in 1/4 of the locations

so a language is TWICE AS VERBOSE WITH ONE QUARTER OF THE PORTABILITY
can I use vb dotnet code in a SQL 2000 or a SQL 2005 _JOB_??

On Feb 12, 6:37 pm, "Zytan" <[e-mail]:

I think that simply importing a namespace into the file is evil (or
something close to it). My (personal, mind you) rule of thumb is, if I
must use Imports, then I must create an alias to it:

Imports SysThread = System.Threading
Imports SysRegex = System.Text.RegularExpression

As opposed to:

Imports System.Threading
Imports System.Text.RegularExpression

Wow! I didn't know you could do that!

Don't know if this relates to what you're talking about, and my
apologies if it drifts to OT.

No apologies needed! This is exactly what I am talking about! I
totally agree that importing namespaces is evil. I want to learn the
language properly, so it is important for me to know where things
are. I've been writing everything out explicitly. But, in doing so,
I can see why people get tired of it (although IntelliSense helps a
ton). But... your suggestion above is a very good answer to this, as
it saves typing, but requires the shorthand so that you remember where
the darn thing actually exists.

Great idea. And great concept that they implemented. thanks!

Zytan

[aaron.kempf]

modules support encapsulation just as much as classes do.
but I do not need to duplicate my code within 500 different modules

modules support code reuse, classes do not

your idiot computer science professor was trying to convince you to
become a C++ _FAG_

the concept is called 'egocentrism'-- whatever he does is the right
route to go

(when in fact, vb won the war, but MS threw the world series; MS
surrendered and betrayed us all)

On Feb 12, 6:46 pm, "Zytan" <[e-mail]:

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

Yes, right, of course. So you can reference the methods from the
module name. But you don't have to. Because you don't have to, I
don't feel like they are locked in there as they should be. But, they
are encapsulated, that's for sure.

For classes with shared functions, you don't need to instantiate them,
either, but yeah, it seems like a 'hack' to make it act like a module,
I know.

Zytan

[aaron.kempf]

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

On Feb 12, 10:39 pm, "Tom Shelton" <[e-mail]:

On Feb 12, 7:30 pm, "Zytan" <[e-mail]:

that would sure be interesting to me

so I can make a class named 'aaron' and I can put functions in it..
and I can reuse those functions without instantiating a class?

I just don't like all of the dependencies between that style of
writing; it makes me sick to think about it

Dependencies are bad for sure. But, I am not sure what writing style
you are referring to that has dependencies? Using Modules? Using
Classes? The only 'dependency' I can see is that Classes are forced
to have everything Shared to act as a Module, but this is reinforced
if ever you attempt to use a function, so it's ok.

Zytan

Your 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, wether you use classes
or modules.

--
Tom Shelton

[aaron.kempf]

neither is worse than the other?

classes are more verbose, slower performance and no tangible benefit

On Feb 13, 5:16 am, "Zytan" <[e-mail]:

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]

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" <[e-mail]:

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]

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" <[e-mail]:

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

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 VehicleWithEngine
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=Value
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=Value
EndIf
End Set
End Property
End Class

Public Class Car
Inherits VehicleWithEngine
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 VehicleWithEngine
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 VehicleWithEngine) 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]]

"Zytan" <zy**********@yahoo.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==?=]

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.

"aa*********@gmail.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.

<[e-mail] in message

news:11*********************@p10g2000cwp.googlegro ups.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 <[e-mail]:
>"Zytan" <[e-mail] in news:1171055866.052844.204220
>@h3g2000cwc.googlegroups.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]

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]

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]

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]

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]

modules support code reuse, classes do not

Now that's just silly.

Zytan

[Scott M.]

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

On Feb 13, 10:23 am, "[e-mail]" <[e-mail]>
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.DoCoollStuff()

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]

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." <[e-mail]:

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 VehicleWithEngine
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=Value
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=Value
EndIf
End Set
End Property
End Class

Public Class Car
Inherits VehicleWithEngine
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 VehicleWithEngine
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 VehicleWithEngine) 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]

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." <[e-mail]:

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 VehicleWithEngine
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=Value
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=Value
EndIf
End Set
End Property
End Class

Public Class Car
Inherits VehicleWithEngine
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 VehicleWithEngine
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 VehicleWithEngine) 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]

I mean seriously here

C# is faster than VB in like ONE situation that is never practical;
and all of a sudden; everyone flocks to C#

PROGRAMMING WITHOUT CLASSES IS MORE MAINTAINABLE, FASTER AND LESS
VERBOSE.

Are you guys from MARS?

On Feb 13, 9:42 am, "Martin H." <[e-mail]:

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 VehicleWithEngine
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=Value
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=Value
EndIf
End Set
End Property
End Class

Public Class Car
Inherits VehicleWithEngine
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 VehicleWithEngine
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 VehicleWithEngine) 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]

Rich

did you bother counting the lines of code?

your vb dotnet way to do it is MORE VERBOSE

On Feb 13, 12:53 pm, Rich <[e-mail]:

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.

"[e-mail]" 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.

<[e-mail] in message

>news:11*********************@p10g2000cwp.googlegr oups.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 <[e-mail]:
"Zytan" <[e-mail] in news:1171055866.052844.204220
@h3g2000cwc.googlegroups.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 :-)- Hide quoted text -

- Show quoted text -

[aaron.kempf]

Zytan

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

WHAT THE HELL IS WRONG WITH YOU?

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 fucking yesman, selling your soul for
the wrong causes
FUCK MS AND FUCK CLASSES

80% of Vb6 developers 'never needed a class'

UNNECESSARY CHANGE IS NOT _SEXY_

UNNECESSARY CHANGE IS NOT _HELPFUL_

UNNECESSARY CHANGE IS NOT _NECESSARY_

On Feb 13, 2:36 pm, "Zytan" <[e-mail]:

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

[aaron.kempf]

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

On Feb 13, 2:41 pm, "Zytan" <[e-mail]:

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

[aaron.kempf]

Scott;

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

come talk about c# to my face, BITCH
this is a VB newsgroup; mother fucker 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 fucking 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 fuck yourself.

if you do accept it as fact and you keep on using classes then you can
still fuck yourself
On Feb 13, 2:47 pm, "Scott M." <[e-mail]:

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.

[aaron.kempf]

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.

On Feb 13, 2:55 pm, "Tom Shelton" <[e-mail]:

On Feb 13, 10:23 am, "[e-mail]" <[e-mail]>
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.DoCoollStuff()

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

[Zytan]

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

[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

[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 fucking yesman, selling your soul for
the wrong causes

FUCK MS AND FUCK 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

[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

[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

[Jay Parzych]

please STFU.

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" <[e-mail]:

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

[Jay Parzych]

please provide MS press titles and page numbers

Scott;

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

come talk about c# to my face, BITCH

this is a VB newsgroup; mother fucker 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 fucking 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 fuck yourself.

if you do accept it as fact and you keep on using classes then you can
still fuck yourself

On Feb 13, 2:47 pm, "Scott M." <[e-mail]:

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

On 2007-02-14, Zytan <zy**********@yahoo.comwrote:

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.

--
Tom Shelton

[Cor Ligthert [MVP]]

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