Understanding Public Module or Class

[Rudy]

Hello All!

I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Tex t)
Wage = CDec(txbTotWage .Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.For mat(PO)
End Sub
So I know I can call this up anywhere within that form. But now I need to
use this in form "b". The textboxes are in place in form "b", same name and
everything else. So a couple of things about this. First, will I run into
problems if I have textboxes named the same in two diffrent forms? Would I
use a public Class, or Module. I guess I don't understand the diffrence. And
I would I call up this in Form "B"?

TIA!!!

Rudy

[Kevin Spencer]

I'm not going to answer your second question, because you need to understand
the Platform and OOP a bit better in order to be able to answer that sort of
question. After all, it will frame itself as a different question every
time, depending on the circumstances. What I *am* going to do is to explain
the difference between a Class and a Module.

I see you're using VB.Net. I can't tell whether you've had previous
programming experience before, or whether you were a VB developer prior to
this. But I want you to understand this from a historical perspective.
Classic VB is a *pseudo* object-oriented programming language. That is, it
does not conform to all of the principles of OOP, and is, in fact, a
procedural language. It does not support inheritance, nor does it provide
much in the way of encapsulation. In fact, VB has a long tradition of using
late binding variants for data. Its history is that of a quick and dirty
type of development.

The .Net platform and the Common Language Infrastructure are truly
object-oriented, and strongly-typed. For VB to make the transition to the
..Net platform, a number of changes had to be made. There are no variants in
..Net. There is, however, the next "best" thing, a base class for everything
called System.Object. And the VB.Net development team did a lot of work to
make VB.Net as familiar to VB programmers as possible. Among these was the
incorporation of the Module into the .Net platform.

The Module is actually a static (Shared) Class, with all Shared and Public
members. It violates virtually every principle of object-orientation. It
cannot inherit other than from System.Object. Everything in it is public,
and globally scoped. It is not polymorphic. Even the .Net SDK states:

"Classes are object-oriented, but modules are not. So only classes can be
instantiated as objects. "

Basically, the Module is a holdover from Classic VB which Microsoft worked
into the .Net platform to keep VB developers happy. Under the covers, it is
a Class. But the compiler will confine it to work within the parameters that
make it act like a classic VB Module.

Now, I'm going to insert some opinion here. IMHO, Microsoft went too far in
accomodating the VB crowd, and ended up giving them enough rope to hang
themselves. The .Net platform is object-oriented, and a person can't muster
the discipline to learn how OOP works and why, he or she ought to stick to
procedural development. It is too easy to get into some big trouble in the
..Net platform if you start playing fast and loose with scope. Yes, it
requires a bit more thought to design classes that properly encapsulate
themselves, but it saves one beaucoups problems down the road in terms of
bugs and maintenance nightmares. But I'm not going to go any farther with
that little controversy! ;-)

I'll just part with this advice: Learn about OOP, inheritance,
encapsulation, polymorphism, whatever you can about how OOP works. It will
save you a great deal of heartache down the road. And avoid Modules, as they
are not object-oriented, and it's far too easy to make a "global variable"
that everything in your application has access to. When something goes
wrong, it'll be darned hard to track it down.

Modules can be used effectively, just as static (Shared) Classes, Methods,
Properties, etc. But one should always be sure that good encapsulation (read
"insulation " if you will) is practiced, as much as possible. Keep the
"visibility " of your data on a "need to know" basis.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Rudy" <Ru**@discussio ns.microsoft.co mwrote in message
news:A8******** *************** ***********@mic rosoft.com...

Hello All!

I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Tex t)
Wage = CDec(txbTotWage .Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.For mat(PO)
End Sub
So I know I can call this up anywhere within that form. But now I need to
use this in form "b". The textboxes are in place in form "b", same name
and
everything else. So a couple of things about this. First, will I run into
problems if I have textboxes named the same in two diffrent forms? Would I
use a public Class, or Module. I guess I don't understand the diffrence.
And
I would I call up this in Form "B"?

TIA!!!

Rudy

[Cor Ligthert [MVP]]

Kevin,

It is nice that you write so much about a VB.Net module, however it is not
true.

By instance a VB.Net module can have private members.

However this is a C# newsgroup, so I will not spoil it with an example about
that.

Cor

"Kevin Spencer" <uc*@ftc.govsch reef in bericht
news:OU******** ******@TK2MSFTN GP05.phx.gbl...

I'm not going to answer your second question, because you need to
understand the Platform and OOP a bit better in order to be able to answer
that sort of question. After all, it will frame itself as a different
question every time, depending on the circumstances. What I *am* going to
do is to explain the difference between a Class and a Module.

I see you're using VB.Net. I can't tell whether you've had previous
programming experience before, or whether you were a VB developer prior to
this. But I want you to understand this from a historical perspective.
Classic VB is a *pseudo* object-oriented programming language. That is, it
does not conform to all of the principles of OOP, and is, in fact, a
procedural language. It does not support inheritance, nor does it provide
much in the way of encapsulation. In fact, VB has a long tradition of
using late binding variants for data. Its history is that of a quick and
dirty type of development.

The .Net platform and the Common Language Infrastructure are truly
object-oriented, and strongly-typed. For VB to make the transition to the
.Net platform, a number of changes had to be made. There are no variants
in .Net. There is, however, the next "best" thing, a base class for
everything called System.Object. And the VB.Net development team did a lot
of work to make VB.Net as familiar to VB programmers as possible. Among
these was the incorporation of the Module into the .Net platform.

The Module is actually a static (Shared) Class, with all Shared and Public
members. It violates virtually every principle of object-orientation. It
cannot inherit other than from System.Object. Everything in it is public,
and globally scoped. It is not polymorphic. Even the .Net SDK states:

"Classes are object-oriented, but modules are not. So only classes can be
instantiated as objects. "

Basically, the Module is a holdover from Classic VB which Microsoft worked
into the .Net platform to keep VB developers happy. Under the covers, it
is a Class. But the compiler will confine it to work within the parameters
that make it act like a classic VB Module.

Now, I'm going to insert some opinion here. IMHO, Microsoft went too far
in accomodating the VB crowd, and ended up giving them enough rope to hang
themselves. The .Net platform is object-oriented, and a person can't
muster the discipline to learn how OOP works and why, he or she ought to
stick to procedural development. It is too easy to get into some big
trouble in the .Net platform if you start playing fast and loose with
scope. Yes, it requires a bit more thought to design classes that properly
encapsulate themselves, but it saves one beaucoups problems down the road
in terms of bugs and maintenance nightmares. But I'm not going to go any
farther with that little controversy! ;-)

I'll just part with this advice: Learn about OOP, inheritance,
encapsulation, polymorphism, whatever you can about how OOP works. It will
save you a great deal of heartache down the road. And avoid Modules, as
they are not object-oriented, and it's far too easy to make a "global
variable" that everything in your application has access to. When
something goes wrong, it'll be darned hard to track it down.

Modules can be used effectively, just as static (Shared) Classes, Methods,
Properties, etc. But one should always be sure that good encapsulation
(read "insulation " if you will) is practiced, as much as possible. Keep
the "visibility " of your data on a "need to know" basis.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Rudy" <Ru**@discussio ns.microsoft.co mwrote in message
news:A8******** *************** ***********@mic rosoft.com...

>Hello All!

I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Tex t)
Wage = CDec(txbTotWage .Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.For mat(PO)
End Sub
So I know I can call this up anywhere within that form. But now I need
to
use this in form "b". The textboxes are in place in form "b", same name
and
everything else. So a couple of things about this. First, will I run into
problems if I have textboxes named the same in two diffrent forms? Would
I
use a public Class, or Module. I guess I don't understand the diffrence.
And
I would I call up this in Form "B"?

TIA!!!

Rudy

[Cor Ligthert [MVP]]

Rudy,

These three are almost the same
VB.Net
\\\
Module MyModule
Public myPublic as String
End module
///
Class MyModule
Public shared myPublic as String
End Class
////
The difference is in this that you can use with a module the myPublic
without calling the module (The later is possible as well and much nicer but
this is not a VB.Net newsgroup)

C#
\\\
Class MyModule
{public static string myPublic;}
///

The last two are exact the same.

Although this is an example; in all three I would use properties and private
members instead of the public as it is showed now.

I hope this gives an idea,

Cor

"Rudy" <Ru**@discussio ns.microsoft.co mschreef in bericht
news:A8******** *************** ***********@mic rosoft.com...

Hello All!

I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Tex t)
Wage = CDec(txbTotWage .Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.For mat(PO)
End Sub
So I know I can call this up anywhere within that form. But now I need to
use this in form "b". The textboxes are in place in form "b", same name
and
everything else. So a couple of things about this. First, will I run into
problems if I have textboxes named the same in two diffrent forms? Would I
use a public Class, or Module. I guess I don't understand the diffrence.
And
I would I call up this in Form "B"?

TIA!!!

Rudy

[Cor Ligthert [MVP]]

Kevin,

Sorry at the end you explain it that it has nothing to do with VB.Net, so I
take it back, however in my idea you should not spoil this newsgroups with
telling about classic VB implementations . I don't see this done in other
newsgroups when it is about C# that there is told about classic C.

For me it was at first sight about a big explanation why C# is better than
VB.Net and I assumed that the avarage visitor will do that the same, only in
your last lines you explain that VB.Net modules can be used as shared
(static) classes with encapsulation.

(I saw it by reading your message more complete after that I answered my
reply to Rudy)

However, sorry for my first reaction.

Cor

"Kevin Spencer" <uc*@ftc.govsch reef in bericht
news:OU******** ******@TK2MSFTN GP05.phx.gbl...

I'm not going to answer your second question, because you need to
understand the Platform and OOP a bit better in order to be able to answer
that sort of question. After all, it will frame itself as a different
question every time, depending on the circumstances. What I *am* going to
do is to explain the difference between a Class and a Module.

I see you're using VB.Net. I can't tell whether you've had previous
programming experience before, or whether you were a VB developer prior to
this. But I want you to understand this from a historical perspective.
Classic VB is a *pseudo* object-oriented programming language. That is, it
does not conform to all of the principles of OOP, and is, in fact, a
procedural language. It does not support inheritance, nor does it provide
much in the way of encapsulation. In fact, VB has a long tradition of
using late binding variants for data. Its history is that of a quick and
dirty type of development.

The .Net platform and the Common Language Infrastructure are truly
object-oriented, and strongly-typed. For VB to make the transition to the
.Net platform, a number of changes had to be made. There are no variants
in .Net. There is, however, the next "best" thing, a base class for
everything called System.Object. And the VB.Net development team did a lot
of work to make VB.Net as familiar to VB programmers as possible. Among
these was the incorporation of the Module into the .Net platform.

The Module is actually a static (Shared) Class, with all Shared and Public
members. It violates virtually every principle of object-orientation. It
cannot inherit other than from System.Object. Everything in it is public,
and globally scoped. It is not polymorphic. Even the .Net SDK states:

"Classes are object-oriented, but modules are not. So only classes can be
instantiated as objects. "

Basically, the Module is a holdover from Classic VB which Microsoft worked
into the .Net platform to keep VB developers happy. Under the covers, it
is a Class. But the compiler will confine it to work within the parameters
that make it act like a classic VB Module.

Now, I'm going to insert some opinion here. IMHO, Microsoft went too far
in accomodating the VB crowd, and ended up giving them enough rope to hang
themselves. The .Net platform is object-oriented, and a person can't
muster the discipline to learn how OOP works and why, he or she ought to
stick to procedural development. It is too easy to get into some big
trouble in the .Net platform if you start playing fast and loose with
scope. Yes, it requires a bit more thought to design classes that properly
encapsulate themselves, but it saves one beaucoups problems down the road
in terms of bugs and maintenance nightmares. But I'm not going to go any
farther with that little controversy! ;-)

I'll just part with this advice: Learn about OOP, inheritance,
encapsulation, polymorphism, whatever you can about how OOP works. It will
save you a great deal of heartache down the road. And avoid Modules, as
they are not object-oriented, and it's far too easy to make a "global
variable" that everything in your application has access to. When
something goes wrong, it'll be darned hard to track it down.

Modules can be used effectively, just as static (Shared) Classes, Methods,
Properties, etc. But one should always be sure that good encapsulation
(read "insulation " if you will) is practiced, as much as possible. Keep
the "visibility " of your data on a "need to know" basis.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Rudy" <Ru**@discussio ns.microsoft.co mwrote in message
news:A8******** *************** ***********@mic rosoft.com...

>Hello All!

I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Tex t)
Wage = CDec(txbTotWage .Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.For mat(PO)
End Sub
So I know I can call this up anywhere within that form. But now I need
to
use this in form "b". The textboxes are in place in form "b", same name
and
everything else. So a couple of things about this. First, will I run into
problems if I have textboxes named the same in two diffrent forms? Would
I
use a public Class, or Module. I guess I don't understand the diffrence.
And
I would I call up this in Form "B"?

TIA!!!

Rudy

[Cor Ligthert [MVP]]

This is not a C# newsgroup, I had my pointer on that while I was writing
this.

:-)

Cor

"Cor Ligthert [MVP]" <no************ @planet.nlschre ef in bericht
news:uZ******** ******@TK2MSFTN GP05.phx.gbl...

Kevin,

It is nice that you write so much about a VB.Net module, however it is not
true.

By instance a VB.Net module can have private members.

However this is a C# newsgroup, so I will not spoil it with an example
about that.

Cor

"Kevin Spencer" <uc*@ftc.govsch reef in bericht
news:OU******** ******@TK2MSFTN GP05.phx.gbl...

>I'm not going to answer your second question, because you need to
understand the Platform and OOP a bit better in order to be able to
answer that sort of question. After all, it will frame itself as a
different question every time, depending on the circumstances. What I
*am* going to do is to explain the difference between a Class and a
Module.

I see you're using VB.Net. I can't tell whether you've had previous
programming experience before, or whether you were a VB developer prior
to this. But I want you to understand this from a historical perspective.
Classic VB is a *pseudo* object-oriented programming language. That is,
it does not conform to all of the principles of OOP, and is, in fact, a
procedural language. It does not support inheritance, nor does it provide
much in the way of encapsulation. In fact, VB has a long tradition of
using late binding variants for data. Its history is that of a quick and
dirty type of development.

The .Net platform and the Common Language Infrastructure are truly
object-oriented, and strongly-typed. For VB to make the transition to the
.Net platform, a number of changes had to be made. There are no variants
in .Net. There is, however, the next "best" thing, a base class for
everything called System.Object. And the VB.Net development team did a
lot of work to make VB.Net as familiar to VB programmers as possible.
Among these was the incorporation of the Module into the .Net platform.

The Module is actually a static (Shared) Class, with all Shared and
Public members. It violates virtually every principle of
object-orientation. It cannot inherit other than from System.Object.
Everything in it is public, and globally scoped. It is not polymorphic.
Even the .Net SDK states:

"Classes are object-oriented, but modules are not. So only classes can be
instantiated as objects. "

Basically, the Module is a holdover from Classic VB which Microsoft
worked into the .Net platform to keep VB developers happy. Under the
covers, it is a Class. But the compiler will confine it to work within
the parameters that make it act like a classic VB Module.

Now, I'm going to insert some opinion here. IMHO, Microsoft went too far
in accomodating the VB crowd, and ended up giving them enough rope to
hang themselves. The .Net platform is object-oriented, and a person can't
muster the discipline to learn how OOP works and why, he or she ought to
stick to procedural development. It is too easy to get into some big
trouble in the .Net platform if you start playing fast and loose with
scope. Yes, it requires a bit more thought to design classes that
properly encapsulate themselves, but it saves one beaucoups problems down
the road in terms of bugs and maintenance nightmares. But I'm not going
to go any farther with that little controversy! ;-)

I'll just part with this advice: Learn about OOP, inheritance,
encapsulatio n, polymorphism, whatever you can about how OOP works. It
will save you a great deal of heartache down the road. And avoid Modules,
as they are not object-oriented, and it's far too easy to make a "global
variable" that everything in your application has access to. When
something goes wrong, it'll be darned hard to track it down.

Modules can be used effectively, just as static (Shared) Classes,
Methods, Properties, etc. But one should always be sure that good
encapsulatio n (read "insulation " if you will) is practiced, as much as
possible. Keep the "visibility " of your data on a "need to know" basis.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Rudy" <Ru**@discussio ns.microsoft.co mwrote in message
news:A8******* *************** ************@mi crosoft.com...

>>Hello All!

I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Tex t)
Wage = CDec(txbTotWage .Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.For mat(PO)
End Sub
So I know I can call this up anywhere within that form. But now I need
to
use this in form "b". The textboxes are in place in form "b", same name
and
everything else. So a couple of things about this. First, will I run
into
problems if I have textboxes named the same in two diffrent forms? Would
I
use a public Class, or Module. I guess I don't understand the diffrence.
And
I would I call up this in Form "B"?

TIA!!!

Rudy

[Kevin Spencer]

Hi Cor,

Sorry you feel that way. My intent was to inform the OP, whose question was
about the difference between Module and Class. What I wrote was simply fact,
not only explaining the difference, but explaining why the Module exists at
all, which it should not (IMHO), by all rights, as it is not object-oriented
(by Microsoft's own admission in the SDK). I have seen Modules abused
entirely too often, and my intent was to provide a reasonable framework in
which the OP could make an educated decision. And this danger of abusing
static, globally-scoped class members in particular was what I wanted to
warn the OP about.

I was incorrect about one thing you pointed out: Module members can have
scope other than Public; they are only Public by default (if you do not
specify the scope). Other than that, however, everything I wrote was
factually correct. Thank you for pointing out the error.

My opinion is based simply on my impression (from observation) that VB.Net
makes it too easy for former classic VB developers to migrate to the .Net
platform without understanding OOP. This happened as a result of Microsoft's
decision to try and make the language *look* as much as possible like
classic VB, which I theorize was for the purpose of not losing their classic
VB base. However, I don't believe there was any real danger of that, as any
other language chosen would look and behave *less* like classic VB, even if
Microsoft had not been so accomodating. Having no better alternative,
classic VB developers would be forced to learn to think OOP. And that would
have prevented a whole slew of issues I have observed with many VB.Net
developers (not all, of course) over the past 5 years, and much of the code
I've seen.

I could not in good conscience not point out the dangers inherent in
treating VB.Net like classic VB. It was not my intent to slander anyone or
to push anyone's "hot buttons" in doing so. Still, I have to wonder why
VB.Net developers in general seem to be so *emotional* about their
"favorite" programming language. It's a fine programming language, but like
anything else it could be better. And the plethora of problems experienced
by classic VB developers in making the change seems to indicate that some
problems exist. I am simply trying to analyze the problems to determine the
root cause, and help others to avoid the pitfalls along the way.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Cor Ligthert [MVP]" <no************ @planet.nlwrote in message
news:e6******** ******@TK2MSFTN GP03.phx.gbl...

Kevin,

Sorry at the end you explain it that it has nothing to do with VB.Net, so
I take it back, however in my idea you should not spoil this newsgroups
with telling about classic VB implementations . I don't see this done in
other newsgroups when it is about C# that there is told about classic C.

For me it was at first sight about a big explanation why C# is better than
VB.Net and I assumed that the avarage visitor will do that the same, only
in your last lines you explain that VB.Net modules can be used as shared
(static) classes with encapsulation.

(I saw it by reading your message more complete after that I answered my
reply to Rudy)

However, sorry for my first reaction.

Cor

"Kevin Spencer" <uc*@ftc.govsch reef in bericht
news:OU******** ******@TK2MSFTN GP05.phx.gbl...

>I'm not going to answer your second question, because you need to
understand the Platform and OOP a bit better in order to be able to
answer that sort of question. After all, it will frame itself as a
different question every time, depending on the circumstances. What I
*am* going to do is to explain the difference between a Class and a
Module.

I see you're using VB.Net. I can't tell whether you've had previous
programming experience before, or whether you were a VB developer prior
to this. But I want you to understand this from a historical perspective.
Classic VB is a *pseudo* object-oriented programming language. That is,
it does not conform to all of the principles of OOP, and is, in fact, a
procedural language. It does not support inheritance, nor does it provide
much in the way of encapsulation. In fact, VB has a long tradition of
using late binding variants for data. Its history is that of a quick and
dirty type of development.

The .Net platform and the Common Language Infrastructure are truly
object-oriented, and strongly-typed. For VB to make the transition to the
.Net platform, a number of changes had to be made. There are no variants
in .Net. There is, however, the next "best" thing, a base class for
everything called System.Object. And the VB.Net development team did a
lot of work to make VB.Net as familiar to VB programmers as possible.
Among these was the incorporation of the Module into the .Net platform.

The Module is actually a static (Shared) Class, with all Shared and
Public members. It violates virtually every principle of
object-orientation. It cannot inherit other than from System.Object.
Everything in it is public, and globally scoped. It is not polymorphic.
Even the .Net SDK states:

"Classes are object-oriented, but modules are not. So only classes can be
instantiated as objects. "

Basically, the Module is a holdover from Classic VB which Microsoft
worked into the .Net platform to keep VB developers happy. Under the
covers, it is a Class. But the compiler will confine it to work within
the parameters that make it act like a classic VB Module.

Now, I'm going to insert some opinion here. IMHO, Microsoft went too far
in accomodating the VB crowd, and ended up giving them enough rope to
hang themselves. The .Net platform is object-oriented, and a person can't
muster the discipline to learn how OOP works and why, he or she ought to
stick to procedural development. It is too easy to get into some big
trouble in the .Net platform if you start playing fast and loose with
scope. Yes, it requires a bit more thought to design classes that
properly encapsulate themselves, but it saves one beaucoups problems down
the road in terms of bugs and maintenance nightmares. But I'm not going
to go any farther with that little controversy! ;-)

I'll just part with this advice: Learn about OOP, inheritance,
encapsulatio n, polymorphism, whatever you can about how OOP works. It
will save you a great deal of heartache down the road. And avoid Modules,
as they are not object-oriented, and it's far too easy to make a "global
variable" that everything in your application has access to. When
something goes wrong, it'll be darned hard to track it down.

Modules can be used effectively, just as static (Shared) Classes,
Methods, Properties, etc. But one should always be sure that good
encapsulatio n (read "insulation " if you will) is practiced, as much as
possible. Keep the "visibility " of your data on a "need to know" basis.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Rudy" <Ru**@discussio ns.microsoft.co mwrote in message
news:A8******* *************** ************@mi crosoft.com...

>>Hello All!

I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Tex t)
Wage = CDec(txbTotWage .Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.For mat(PO)
End Sub
So I know I can call this up anywhere within that form. But now I need
to
use this in form "b". The textboxes are in place in form "b", same name
and
everything else. So a couple of things about this. First, will I run
into
problems if I have textboxes named the same in two diffrent forms? Would
I
use a public Class, or Module. I guess I don't understand the diffrence.
And
I would I call up this in Form "B"?

TIA!!!

Rudy

[Cor Ligthert [MVP]]

Kevin,

We have probably the same opinion, I showed with that idea the little
samples to the OOP, if I had seen that it was in this newsgroup I had made
them with properties..

A module or a static/shared class (whatever you name that), has in my
opinion nothing to do with OOP than that it is needed to have a start
somewhere and would be avoided as that is possible. I had however a week ago
a long discussion with that with Jon Skeet and a short with Nick what is
maybe the reason that I reacted so quick on your message. I was in that
discussion not even telling it in that way, because I am not such a puritan
as you probably have seen. Personally I find that it should be avoided as
much as possible, but everybody is free to do as he wants.

I stay with the fact that it becomes time that we are not using VB6 anymore
as samples, it is too often direct related to VB.Net for those who don't
know that language. As I say that C# has a lot of legacy from classic C,
than I can almost for sure wait on a reaction from Jon Skeet, while it is a
fact (as VB.Net has in my idea much legacy from classic VB before you
misunderstand me).

Your message has however made me thinking, so I will probably ask on another
place if there is no change possible between the Public, Friend, etc members
from a module in a way that they never can be used without there module
name. Than it becomes in my idea a nicer way to create so called shared
classes. Than that awful dim can keep is own behaviour.

Cor

"Kevin Spencer" <uc*@ftc.govsch reef in bericht
news:%2******** ********@TK2MSF TNGP06.phx.gbl. ..

Hi Cor,

Sorry you feel that way. My intent was to inform the OP, whose question
was about the difference between Module and Class. What I wrote was simply
fact, not only explaining the difference, but explaining why the Module
exists at all, which it should not (IMHO), by all rights, as it is not
object-oriented (by Microsoft's own admission in the SDK). I have seen
Modules abused entirely too often, and my intent was to provide a
reasonable framework in which the OP could make an educated decision. And
this danger of abusing static, globally-scoped class members in particular
was what I wanted to warn the OP about.

I was incorrect about one thing you pointed out: Module members can have
scope other than Public; they are only Public by default (if you do not
specify the scope). Other than that, however, everything I wrote was
factually correct. Thank you for pointing out the error.

My opinion is based simply on my impression (from observation) that VB.Net
makes it too easy for former classic VB developers to migrate to the .Net
platform without understanding OOP. This happened as a result of
Microsoft's decision to try and make the language *look* as much as
possible like classic VB, which I theorize was for the purpose of not
losing their classic VB base. However, I don't believe there was any real
danger of that, as any other language chosen would look and behave *less*
like classic VB, even if Microsoft had not been so accomodating. Having no
better alternative, classic VB developers would be forced to learn to
think OOP. And that would have prevented a whole slew of issues I have
observed with many VB.Net developers (not all, of course) over the past 5
years, and much of the code I've seen.

I could not in good conscience not point out the dangers inherent in
treating VB.Net like classic VB. It was not my intent to slander anyone or
to push anyone's "hot buttons" in doing so. Still, I have to wonder why
VB.Net developers in general seem to be so *emotional* about their
"favorite" programming language. It's a fine programming language, but
like anything else it could be better. And the plethora of problems
experienced by classic VB developers in making the change seems to
indicate that some problems exist. I am simply trying to analyze the
problems to determine the root cause, and help others to avoid the
pitfalls along the way.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Cor Ligthert [MVP]" <no************ @planet.nlwrote in message
news:e6******** ******@TK2MSFTN GP03.phx.gbl...

>Kevin,

Sorry at the end you explain it that it has nothing to do with VB.Net,
so I take it back, however in my idea you should not spoil this
newsgroups with telling about classic VB implementations . I don't see
this done in other newsgroups when it is about C# that there is told
about classic C.

For me it was at first sight about a big explanation why C# is better
than VB.Net and I assumed that the avarage visitor will do that the same,
only in your last lines you explain that VB.Net modules can be used as
shared (static) classes with encapsulation.

(I saw it by reading your message more complete after that I answered my
reply to Rudy)

However, sorry for my first reaction.

Cor

"Kevin Spencer" <uc*@ftc.govsch reef in bericht
news:OU******* *******@TK2MSFT NGP05.phx.gbl.. .

>>I'm not going to answer your second question, because you need to
understand the Platform and OOP a bit better in order to be able to
answer that sort of question. After all, it will frame itself as a
different question every time, depending on the circumstances. What I
*am* going to do is to explain the difference between a Class and a
Module.

I see you're using VB.Net. I can't tell whether you've had previous
programming experience before, or whether you were a VB developer prior
to this. But I want you to understand this from a historical
perspective . Classic VB is a *pseudo* object-oriented programming
language. That is, it does not conform to all of the principles of OOP,
and is, in fact, a procedural language. It does not support inheritance,
nor does it provide much in the way of encapsulation. In fact, VB has a
long tradition of using late binding variants for data. Its history is
that of a quick and dirty type of development.

The .Net platform and the Common Language Infrastructure are truly
object-oriented, and strongly-typed. For VB to make the transition to
the .Net platform, a number of changes had to be made. There are no
variants in .Net. There is, however, the next "best" thing, a base class
for everything called System.Object. And the VB.Net development team did
a lot of work to make VB.Net as familiar to VB programmers as possible.
Among these was the incorporation of the Module into the .Net platform.

The Module is actually a static (Shared) Class, with all Shared and
Public members. It violates virtually every principle of
object-orientation. It cannot inherit other than from System.Object.
Everything in it is public, and globally scoped. It is not polymorphic.
Even the .Net SDK states:

"Classes are object-oriented, but modules are not. So only classes can
be instantiated as objects. "

Basically, the Module is a holdover from Classic VB which Microsoft
worked into the .Net platform to keep VB developers happy. Under the
covers, it is a Class. But the compiler will confine it to work within
the parameters that make it act like a classic VB Module.

Now, I'm going to insert some opinion here. IMHO, Microsoft went too far
in accomodating the VB crowd, and ended up giving them enough rope to
hang themselves. The .Net platform is object-oriented, and a person
can't muster the discipline to learn how OOP works and why, he or she
ought to stick to procedural development. It is too easy to get into
some big trouble in the .Net platform if you start playing fast and
loose with scope. Yes, it requires a bit more thought to design classes
that properly encapsulate themselves, but it saves one beaucoups
problems down the road in terms of bugs and maintenance nightmares. But
I'm not going to go any farther with that little controversy! ;-)

I'll just part with this advice: Learn about OOP, inheritance,
encapsulation , polymorphism, whatever you can about how OOP works. It
will save you a great deal of heartache down the road. And avoid
Modules, as they are not object-oriented, and it's far too easy to make
a "global variable" that everything in your application has access to.
When something goes wrong, it'll be darned hard to track it down.

Modules can be used effectively, just as static (Shared) Classes,
Methods, Properties, etc. But one should always be sure that good
encapsulati on (read "insulation " if you will) is practiced, as much as
possible. Keep the "visibility " of your data on a "need to know" basis.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Rudy" <Ru**@discussio ns.microsoft.co mwrote in message
news:A8****** *************** *************@m icrosoft.com...
Hello All!

I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Tex t)
Wage = CDec(txbTotWage .Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.For mat(PO)
End Sub
So I know I can call this up anywhere within that form. But now I need
to
use this in form "b". The textboxes are in place in form "b", same
name and
everything else. So a couple of things about this. First, will I run
into
problems if I have textboxes named the same in two diffrent forms?
Would I
use a public Class, or Module. I guess I don't understand the
diffrence. And
I would I call up this in Form "B"?

TIA!!!

Rudy

[Rudy]

Thanks Kevin and Cor for the great info. I found the information very
interesting and give me a better idea of what to use.

Thanks again!

Rudy

"Cor Ligthert [MVP]" wrote:

Rudy,

These three are almost the same
VB.Net
\\\
Module MyModule
Public myPublic as String
End module
///
Class MyModule
Public shared myPublic as String
End Class
////
The difference is in this that you can use with a module the myPublic
without calling the module (The later is possible as well and much nicer but
this is not a VB.Net newsgroup)

C#
\\\
Class MyModule
{public static string myPublic;}
///

The last two are exact the same.

Although this is an example; in all three I would use properties and private
members instead of the public as it is showed now.

I hope this gives an idea,

Cor

"Rudy" <Ru**@discussio ns.microsoft.co mschreef in bericht
news:A8******** *************** ***********@mic rosoft.com...

Hello All!

I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Tex t)
Wage = CDec(txbTotWage .Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.For mat(PO)
End Sub
So I know I can call this up anywhere within that form. But now I need to
use this in form "b". The textboxes are in place in form "b", same name
and
everything else. So a couple of things about this. First, will I run into
problems if I have textboxes named the same in two diffrent forms? Would I
use a public Class, or Module. I guess I don't understand the diffrence.
And
I would I call up this in Form "B"?

TIA!!!

Rudy

[Kevin Spencer]

I appreciate your cooperative spirit, Cor!

--

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Cor Ligthert [MVP]" <no************ @planet.nlwrote in message
news:eg******** ******@TK2MSFTN GP04.phx.gbl...

Kevin,

We have probably the same opinion, I showed with that idea the little
samples to the OOP, if I had seen that it was in this newsgroup I had made
them with properties..

A module or a static/shared class (whatever you name that), has in my
opinion nothing to do with OOP than that it is needed to have a start
somewhere and would be avoided as that is possible. I had however a week
ago a long discussion with that with Jon Skeet and a short with Nick what
is maybe the reason that I reacted so quick on your message. I was in that
discussion not even telling it in that way, because I am not such a
puritan as you probably have seen. Personally I find that it should be
avoided as much as possible, but everybody is free to do as he wants.

I stay with the fact that it becomes time that we are not using VB6
anymore as samples, it is too often direct related to VB.Net for those who
don't know that language. As I say that C# has a lot of legacy from
classic C, than I can almost for sure wait on a reaction from Jon Skeet,
while it is a fact (as VB.Net has in my idea much legacy from classic VB
before you misunderstand me).

Your message has however made me thinking, so I will probably ask on
another place if there is no change possible between the Public, Friend,
etc members from a module in a way that they never can be used without
there module name. Than it becomes in my idea a nicer way to create so
called shared classes. Than that awful dim can keep is own behaviour.

Cor

"Kevin Spencer" <uc*@ftc.govsch reef in bericht
news:%2******** ********@TK2MSF TNGP06.phx.gbl. ..

>Hi Cor,

Sorry you feel that way. My intent was to inform the OP, whose question
was about the difference between Module and Class. What I wrote was
simply fact, not only explaining the difference, but explaining why the
Module exists at all, which it should not (IMHO), by all rights, as it is
not object-oriented (by Microsoft's own admission in the SDK). I have
seen Modules abused entirely too often, and my intent was to provide a
reasonable framework in which the OP could make an educated decision. And
this danger of abusing static, globally-scoped class members in
particular was what I wanted to warn the OP about.

I was incorrect about one thing you pointed out: Module members can have
scope other than Public; they are only Public by default (if you do not
specify the scope). Other than that, however, everything I wrote was
factually correct. Thank you for pointing out the error.

My opinion is based simply on my impression (from observation) that
VB.Net makes it too easy for former classic VB developers to migrate to
the .Net platform without understanding OOP. This happened as a result of
Microsoft's decision to try and make the language *look* as much as
possible like classic VB, which I theorize was for the purpose of not
losing their classic VB base. However, I don't believe there was any real
danger of that, as any other language chosen would look and behave *less*
like classic VB, even if Microsoft had not been so accomodating. Having
no better alternative, classic VB developers would be forced to learn to
think OOP. And that would have prevented a whole slew of issues I have
observed with many VB.Net developers (not all, of course) over the past 5
years, and much of the code I've seen.

I could not in good conscience not point out the dangers inherent in
treating VB.Net like classic VB. It was not my intent to slander anyone
or to push anyone's "hot buttons" in doing so. Still, I have to wonder
why VB.Net developers in general seem to be so *emotional* about their
"favorite" programming language. It's a fine programming language, but
like anything else it could be better. And the plethora of problems
experienced by classic VB developers in making the change seems to
indicate that some problems exist. I am simply trying to analyze the
problems to determine the root cause, and help others to avoid the
pitfalls along the way.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Cor Ligthert [MVP]" <no************ @planet.nlwrote in message
news:e6******* *******@TK2MSFT NGP03.phx.gbl.. .

>>Kevin,

Sorry at the end you explain it that it has nothing to do with VB.Net,
so I take it back, however in my idea you should not spoil this
newsgroups with telling about classic VB implementations . I don't see
this done in other newsgroups when it is about C# that there is told
about classic C.

For me it was at first sight about a big explanation why C# is better
than VB.Net and I assumed that the avarage visitor will do that the
same, only in your last lines you explain that VB.Net modules can be
used as shared (static) classes with encapsulation.

(I saw it by reading your message more complete after that I answered my
reply to Rudy)

However, sorry for my first reaction.

Cor

"Kevin Spencer" <uc*@ftc.govsch reef in bericht
news:OU****** ********@TK2MSF TNGP05.phx.gbl. ..
I'm not going to answer your second question, because you need to
understand the Platform and OOP a bit better in order to be able to
answer that sort of question. After all, it will frame itself as a
different question every time, depending on the circumstances. What I
*am* going to do is to explain the difference between a Class and a
Module.

I see you're using VB.Net. I can't tell whether you've had previous
programmin g experience before, or whether you were a VB developer prior
to this. But I want you to understand this from a historical
perspectiv e. Classic VB is a *pseudo* object-oriented programming
language. That is, it does not conform to all of the principles of OOP,
and is, in fact, a procedural language. It does not support
inheritanc e, nor does it provide much in the way of encapsulation. In
fact, VB has a long tradition of using late binding variants for data.
Its history is that of a quick and dirty type of development.

The .Net platform and the Common Language Infrastructure are truly
object-oriented, and strongly-typed. For VB to make the transition to
the .Net platform, a number of changes had to be made. There are no
variants in .Net. There is, however, the next "best" thing, a base
class for everything called System.Object. And the VB.Net development
team did a lot of work to make VB.Net as familiar to VB programmers as
possible. Among these was the incorporation of the Module into the .Net
platform.

The Module is actually a static (Shared) Class, with all Shared and
Public members. It violates virtually every principle of
object-orientation. It cannot inherit other than from System.Object.
Everything in it is public, and globally scoped. It is not polymorphic.
Even the .Net SDK states:

"Classes are object-oriented, but modules are not. So only classes can
be instantiated as objects. "

Basically, the Module is a holdover from Classic VB which Microsoft
worked into the .Net platform to keep VB developers happy. Under the
covers, it is a Class. But the compiler will confine it to work within
the parameters that make it act like a classic VB Module.

Now, I'm going to insert some opinion here. IMHO, Microsoft went too
far in accomodating the VB crowd, and ended up giving them enough rope
to hang themselves. The .Net platform is object-oriented, and a person
can't muster the discipline to learn how OOP works and why, he or she
ought to stick to procedural development. It is too easy to get into
some big trouble in the .Net platform if you start playing fast and
loose with scope. Yes, it requires a bit more thought to design classes
that properly encapsulate themselves, but it saves one beaucoups
problems down the road in terms of bugs and maintenance nightmares. But
I'm not going to go any farther with that little controversy! ;-)

I'll just part with this advice: Learn about OOP, inheritance,
encapsulatio n, polymorphism, whatever you can about how OOP works. It
will save you a great deal of heartache down the road. And avoid
Modules, as they are not object-oriented, and it's far too easy to make
a "global variable" that everything in your application has access to.
When something goes wrong, it'll be darned hard to track it down.

Modules can be used effectively, just as static (Shared) Classes,
Methods, Properties, etc. But one should always be sure that good
encapsulatio n (read "insulation " if you will) is practiced, as much as
possible. Keep the "visibility " of your data on a "need to know" basis.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.

"Rudy" <Ru**@discussio ns.microsoft.co mwrote in message
news:A8***** *************** **************@ microsoft.com.. .
Hello All!
>
I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Tex t)
Wage = CDec(txbTotWage .Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.For mat(PO)
End Sub
So I know I can call this up anywhere within that form. But now I
need to
use this in form "b". The textboxes are in place in form "b", same
name and
everythin g else. So a couple of things about this. First, will I run
into
problems if I have textboxes named the same in two diffrent forms?
Would I
use a public Class, or Module. I guess I don't understand the
diffrence . And
I would I call up this in Form "B"?
>
TIA!!!
>
Rudy