469,898 Members | 1,707 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,898 developers. It's quick & easy.

Global Functions

I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
Dim ConnStrL3Producer As String
ConnStrL3Producer = "User ID=UID;Tag with column collation when
possible=False;Data Source=" & Chr(34) & "a.b.c.d" & Chr(34) &
";Password=PWD;"
ConnStrL3Producer = ConnStrL3Producer & "Initial Catalog=L3;Use Procedure
for Prepare=1;Auto Translate=True;Persist Security Info=True;Provider="
ConnStrL3Producer = ConnStrL3Producer & Chr(34) & "SQLOLEDB.1" & Chr(34) &
";Workstation ID=AUM;Use Encryption for Data=False;Packet Size=4096"
Dim ConnL3Producer As New OleDbConnection(ConnStrL3Producer)
Return ConnL3Producer
End Function

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How can
I use this connection object in all my forms but open it only once? Ideally
I would like to move as much of the intialization (creating the OLEDBAdapter
etc) to the global routine.

Thanx for any suggestions.
--
Anil Gupte
www.keeninc.net
www.icinema.com
Dec 14 '06 #1
23 3335

Well i would not recomend a global connection aproach in .Net

Because of the superb connection pool mechanism , you can now safely and
without anny performance overhead create , use , and destroy
especially the using statement is verry handy with this

personally i would store the connection string in the config file

regards

Michel

"Anil Gupte" <an*******@icinema.comschreef in bericht
news:Of**************@TK2MSFTNGP06.phx.gbl...
>I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
Dim ConnStrL3Producer As String
ConnStrL3Producer = "User ID=UID;Tag with column collation when
possible=False;Data Source=" & Chr(34) & "a.b.c.d" & Chr(34) &
";Password=PWD;"
ConnStrL3Producer = ConnStrL3Producer & "Initial Catalog=L3;Use Procedure
for Prepare=1;Auto Translate=True;Persist Security Info=True;Provider="
ConnStrL3Producer = ConnStrL3Producer & Chr(34) & "SQLOLEDB.1" & Chr(34) &
";Workstation ID=AUM;Use Encryption for Data=False;Packet Size=4096"
Dim ConnL3Producer As New OleDbConnection(ConnStrL3Producer)
Return ConnL3Producer
End Function

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How
can I use this connection object in all my forms but open it only once?
Ideally I would like to move as much of the intialization (creating the
OLEDBAdapter etc) to the global routine.

Thanx for any suggestions.
--
Anil Gupte
www.keeninc.net
www.icinema.com


Dec 14 '06 #2
Thanx for that tip, but please explain:
"...especially the using statement is verry handy with this"

and also
"...personally i would store the connection string in the config file"

I am a newbie at .Net and last used VB five years ago for a few months.

--
Anil Gupte
www.keeninc.net
www.icinema.com

"Michel Posseth [MCP]" <MS**@posseth.comwrote in message
news:eq**************@TK2MSFTNGP04.phx.gbl...
>
Well i would not recomend a global connection aproach in .Net

Because of the superb connection pool mechanism , you can now safely and
without anny performance overhead create , use , and destroy
especially the using statement is verry handy with this

personally i would store the connection string in the config file

regards

Michel

"Anil Gupte" <an*******@icinema.comschreef in bericht
news:Of**************@TK2MSFTNGP06.phx.gbl...
>>I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
Dim ConnStrL3Producer As String
ConnStrL3Producer = "User ID=UID;Tag with column collation when
possible=False;Data Source=" & Chr(34) & "a.b.c.d" & Chr(34) &
";Password=PWD;"
ConnStrL3Producer = ConnStrL3Producer & "Initial Catalog=L3;Use Procedure
for Prepare=1;Auto Translate=True;Persist Security Info=True;Provider="
ConnStrL3Producer = ConnStrL3Producer & Chr(34) & "SQLOLEDB.1" & Chr(34)
& ";Workstation ID=AUM;Use Encryption for Data=False;Packet Size=4096"
Dim ConnL3Producer As New OleDbConnection(ConnStrL3Producer)
Return ConnL3Producer
End Function

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How
can I use this connection object in all my forms but open it only once?
Ideally I would like to move as much of the intialization (creating the
OLEDBAdapter etc) to the global routine.

Thanx for any suggestions.
--
Anil Gupte
www.keeninc.net
www.icinema.com



Dec 14 '06 #3
I can't know if you have but if you haven't heard of design patterns I think
you should spend a little time reading about them. Here is an overview:
http://en.wikipedia.org/wiki/Design_...mputer_science)

Particularly you are describing a Singleton pattern (there is code here in
C# which you can take a look at)
http://en.wikipedia.org/wiki/Singleton_pattern
"Anil Gupte" <an*******@icinema.comwrote in message
news:Of**************@TK2MSFTNGP06.phx.gbl...
>I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
Dim ConnStrL3Producer As String
ConnStrL3Producer = "User ID=UID;Tag with column collation when
possible=False;Data Source=" & Chr(34) & "a.b.c.d" & Chr(34) &
";Password=PWD;"
ConnStrL3Producer = ConnStrL3Producer & "Initial Catalog=L3;Use Procedure
for Prepare=1;Auto Translate=True;Persist Security Info=True;Provider="
ConnStrL3Producer = ConnStrL3Producer & Chr(34) & "SQLOLEDB.1" & Chr(34) &
";Workstation ID=AUM;Use Encryption for Data=False;Packet Size=4096"
Dim ConnL3Producer As New OleDbConnection(ConnStrL3Producer)
Return ConnL3Producer
End Function

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How
can I use this connection object in all my forms but open it only once?
Ideally I would like to move as much of the intialization (creating the
OLEDBAdapter etc) to the global routine.

Thanx for any suggestions.
--
Anil Gupte
www.keeninc.net
www.icinema.com


Dec 14 '06 #4
Hmm, I must be in a parallel universe. Just kidding of course, but I did
not follow most of what I read on those links, and I am not that much of a
programmer (nor do I ever hope to be). I am just building a prototype of
software that I want real programmers to write.

Anyway, if you have seen specific tutorials relating to this, please do let
me know.

Anyway Thanx,
--
Anil Gupte
www.keeninc.net
www.icinema.com

"Tom Leylan" <ge*@iamtiredofspam.comwrote in message
news:eQ*************@TK2MSFTNGP06.phx.gbl...
>I can't know if you have but if you haven't heard of design patterns I
think you should spend a little time reading about them. Here is an
overview: http://en.wikipedia.org/wiki/Design_...mputer_science)

Particularly you are describing a Singleton pattern (there is code here in
C# which you can take a look at)
http://en.wikipedia.org/wiki/Singleton_pattern
"Anil Gupte" <an*******@icinema.comwrote in message
news:Of**************@TK2MSFTNGP06.phx.gbl...
>>I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
Dim ConnStrL3Producer As String
ConnStrL3Producer = "User ID=UID;Tag with column collation when
possible=False;Data Source=" & Chr(34) & "a.b.c.d" & Chr(34) &
";Password=PWD;"
ConnStrL3Producer = ConnStrL3Producer & "Initial Catalog=L3;Use Procedure
for Prepare=1;Auto Translate=True;Persist Security Info=True;Provider="
ConnStrL3Producer = ConnStrL3Producer & Chr(34) & "SQLOLEDB.1" & Chr(34)
& ";Workstation ID=AUM;Use Encryption for Data=False;Packet Size=4096"
Dim ConnL3Producer As New OleDbConnection(ConnStrL3Producer)
Return ConnL3Producer
End Function

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How
can I use this connection object in all my forms but open it only once?
Ideally I would like to move as much of the intialization (creating the
OLEDBAdapter etc) to the global routine.

Thanx for any suggestions.
--
Anil Gupte
www.keeninc.net
www.icinema.com



Dec 14 '06 #5
A fairly common problem developers run into is having non-developers explain
how to develop applications :-) I'll suggest that you ordinarily wouldn't
need to explain to a developer your preference for a single connection,
globally accessible from anywhere in the application. The developer(s) can
figure out a) if that is a good idea and b) how best to implement it.

Design patterns have been around for a very long time but (more or less)
recently were given names and categorized. There are many books and
thousands of articles on the subject but in a nutshell most of what
developers do isn't "new" and whether we are instantiating a customer,
inventory item, baseball score or anything else the process is the same. I
don't mean that the code exists I mean the "pattern" that the code will
follow exists. Your house may look completely different from another but it
will have a foundation, walls and a roof, those are givens.

Bottom line is when you have some time consider reading an introduction
articles on design patterns. If it does nothing else you may have the "aha"
moment when you find something you've been trying to explain to a developer
actually has a name and everybody already knows about it.

Also if you create a singleton class your "I don't want two instances"
problem goes away. There may be a dozen other tricky ways to do it but ask
yourself what is the advantage to not using a proven design that everybody
else is using?

Take care,
Tom
"Anil Gupte" <an*******@icinema.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
Hmm, I must be in a parallel universe. Just kidding of course, but I did
not follow most of what I read on those links, and I am not that much of a
programmer (nor do I ever hope to be). I am just building a prototype of
software that I want real programmers to write.

Anyway, if you have seen specific tutorials relating to this, please do
let me know.

Anyway Thanx,
--
Anil Gupte
www.keeninc.net
www.icinema.com

"Tom Leylan" <ge*@iamtiredofspam.comwrote in message
news:eQ*************@TK2MSFTNGP06.phx.gbl...
>>I can't know if you have but if you haven't heard of design patterns I
think you should spend a little time reading about them. Here is an
overview: http://en.wikipedia.org/wiki/Design_...mputer_science)

Particularly you are describing a Singleton pattern (there is code here
in C# which you can take a look at)
http://en.wikipedia.org/wiki/Singleton_pattern
"Anil Gupte" <an*******@icinema.comwrote in message
news:Of**************@TK2MSFTNGP06.phx.gbl...
>>>I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
Dim ConnStrL3Producer As String
ConnStrL3Producer = "User ID=UID;Tag with column collation when
possible=False;Data Source=" & Chr(34) & "a.b.c.d" & Chr(34) &
";Password=PWD;"
ConnStrL3Producer = ConnStrL3Producer & "Initial Catalog=L3;Use
Procedure for Prepare=1;Auto Translate=True;Persist Security
Info=True;Provider="
ConnStrL3Producer = ConnStrL3Producer & Chr(34) & "SQLOLEDB.1" & Chr(34)
& ";Workstation ID=AUM;Use Encryption for Data=False;Packet Size=4096"
Dim ConnL3Producer As New OleDbConnection(ConnStrL3Producer)
Return ConnL3Producer
End Function

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How
can I use this connection object in all my forms but open it only once?
Ideally I would like to move as much of the intialization (creating the
OLEDBAdapter etc) to the global routine.

Thanx for any suggestions.
--
Anil Gupte
www.keeninc.net
www.icinema.com




Dec 14 '06 #6
Anil Gupte wrote:
I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:
Public Function SetDBConnect()
<snip>
Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How can
I use this connection object in all my forms but open it only once? Ideally
I would like to move as much of the intialization (creating the OLEDBAdapter
etc) to the global routine.
<snip>

I guess you can declare a Module, instead of a class:

<aircode>
Module L3Global
Private mConnection As OleDBConnection

Public Function ConnectDB() As OleDBConnection
If mConnection Is Nothing Then
Dim ConText As String = "Your connection string"
mCOnnection = New OleDBConnectins(ConText)
End If
Return mConnection
End Function
End Module
</aircode>

And then, in your Forms you'd have:

Dim ConnL3Producer _
As OleDbConnection = L3Global.ConnectDB()

Improvise over that.

Regards,

Branco.

Dec 14 '06 #7
Because you are not that much of a programmer (nor do you ever hope to be),
I strongly suggest that you do NOT build a prototype of software that you
want real programmers to write.

Instead, write a specification document that describes, at a fairly high
level, the purpose of the software, what the 'inputs' are, what the
'outputs' must be and what the expected outcomes are. Include details of
business rules and pictures of what various forms and reports should look
like. If there are any aspects of the specification that are immutable then
make those aspect clear and unambiguous. Also include details of what
technologies may or may not be used.

You will find that a real programmer, when presented with such a document,
will have no problems figuring out the best way to implement the design and
will be more productive than having to work from a protoype developed by
someone who doesn't really know what they are doing.
"Anil Gupte" <an*******@icinema.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
Hmm, I must be in a parallel universe. Just kidding of course, but I did
not follow most of what I read on those links, and I am not that much of a
programmer (nor do I ever hope to be). I am just building a prototype of
software that I want real programmers to write.

Anyway, if you have seen specific tutorials relating to this, please do
let me know.

Anyway Thanx,
--
Anil Gupte
www.keeninc.net
www.icinema.com

"Tom Leylan" <ge*@iamtiredofspam.comwrote in message
news:eQ*************@TK2MSFTNGP06.phx.gbl...
>>I can't know if you have but if you haven't heard of design patterns I
think you should spend a little time reading about them. Here is an
overview: http://en.wikipedia.org/wiki/Design_...mputer_science)

Particularly you are describing a Singleton pattern (there is code here
in C# which you can take a look at)
http://en.wikipedia.org/wiki/Singleton_pattern
"Anil Gupte" <an*******@icinema.comwrote in message
news:Of**************@TK2MSFTNGP06.phx.gbl...
>>>I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
Dim ConnStrL3Producer As String
ConnStrL3Producer = "User ID=UID;Tag with column collation when
possible=False;Data Source=" & Chr(34) & "a.b.c.d" & Chr(34) &
";Password=PWD;"
ConnStrL3Producer = ConnStrL3Producer & "Initial Catalog=L3;Use
Procedure for Prepare=1;Auto Translate=True;Persist Security
Info=True;Provider="
ConnStrL3Producer = ConnStrL3Producer & Chr(34) & "SQLOLEDB.1" & Chr(34)
& ";Workstation ID=AUM;Use Encryption for Data=False;Packet Size=4096"
Dim ConnL3Producer As New OleDbConnection(ConnStrL3Producer)
Return ConnL3Producer
End Function

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How
can I use this connection object in all my forms but open it only once?
Ideally I would like to move as much of the intialization (creating the
OLEDBAdapter etc) to the global routine.

Thanx for any suggestions.
--
Anil Gupte
www.keeninc.net
www.icinema.com




Dec 14 '06 #8
Thanx, that will get me started. Do you happen to know any place where I
can read more about when to use a Module and when to use a class?

Thanx again,
--
Anil Gupte
www.keeninc.net
www.icinema.com

"Branco Medeiros" <br*************@gmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
Anil Gupte wrote:
>I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:
>Public Function SetDBConnect()
<snip>
>Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How
can
I use this connection object in all my forms but open it only once?
Ideally
I would like to move as much of the intialization (creating the
OLEDBAdapter
etc) to the global routine.
<snip>

I guess you can declare a Module, instead of a class:

<aircode>
Module L3Global
Private mConnection As OleDBConnection

Public Function ConnectDB() As OleDBConnection
If mConnection Is Nothing Then
Dim ConText As String = "Your connection string"
mCOnnection = New OleDBConnectins(ConText)
End If
Return mConnection
End Function
End Module
</aircode>

And then, in your Forms you'd have:

Dim ConnL3Producer _
As OleDbConnection = L3Global.ConnectDB()

Improvise over that.

Regards,

Branco.

Dec 15 '06 #9
Anil: Yes you can read it right here :-) Never use a module!

VB.Net is an object-oriented language and by definition that should lead to
object-oriented solutions. If there is no OOP solution (and that would seem
unlikely given apps written in SmallTalk, C++, Java, C# and all the other
OOP-based languages) then one might find themselves forced into having to
resort to a "hack". Take my word for it don't start with the "hack" or you
will never stop applying hacks. People will stare at your code and giggle
behind your back...

What you are describing isn't a "module" you are describing a Singleton
Class. If you want to read something perhaps about the Singleton Class
would be a good start.

Try it you may like it.

"Anil Gupte" <an*******@icinema.comwrote in message
news:OC**************@TK2MSFTNGP03.phx.gbl...
Thanx, that will get me started. Do you happen to know any place where I
can read more about when to use a Module and when to use a class?

Thanx again,
--
Anil Gupte
www.keeninc.net
www.icinema.com

"Branco Medeiros" <br*************@gmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
>Anil Gupte wrote:
>>I am trying to set up a function that connects to the database that I
can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:
>>Public Function SetDBConnect()
<snip>
>>Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How
can
I use this connection object in all my forms but open it only once?
Ideally
I would like to move as much of the intialization (creating the
OLEDBAdapter
etc) to the global routine.
<snip>

I guess you can declare a Module, instead of a class:

<aircode>
Module L3Global
Private mConnection As OleDBConnection

Public Function ConnectDB() As OleDBConnection
If mConnection Is Nothing Then
Dim ConText As String = "Your connection string"
mCOnnection = New OleDBConnectins(ConText)
End If
Return mConnection
End Function
End Module
</aircode>

And then, in your Forms you'd have:

Dim ConnL3Producer _
As OleDbConnection = L3Global.ConnectDB()

Improvise over that.

Regards,

Branco.


Dec 16 '06 #10
Funny, I always thought a module was a Singleton Class!
--
Dennis in Houston
"Tom Leylan" wrote:
Anil: Yes you can read it right here :-) Never use a module!

VB.Net is an object-oriented language and by definition that should lead to
object-oriented solutions. If there is no OOP solution (and that would seem
unlikely given apps written in SmallTalk, C++, Java, C# and all the other
OOP-based languages) then one might find themselves forced into having to
resort to a "hack". Take my word for it don't start with the "hack" or you
will never stop applying hacks. People will stare at your code and giggle
behind your back...

What you are describing isn't a "module" you are describing a Singleton
Class. If you want to read something perhaps about the Singleton Class
would be a good start.

Try it you may like it.

"Anil Gupte" <an*******@icinema.comwrote in message
news:OC**************@TK2MSFTNGP03.phx.gbl...
Thanx, that will get me started. Do you happen to know any place where I
can read more about when to use a Module and when to use a class?

Thanx again,
--
Anil Gupte
www.keeninc.net
www.icinema.com

"Branco Medeiros" <br*************@gmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
Anil Gupte wrote:
I am trying to set up a function that connects to the database that I
can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
<snip>

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How
can
I use this connection object in all my forms but open it only once?
Ideally
I would like to move as much of the intialization (creating the
OLEDBAdapter
etc) to the global routine.
<snip>

I guess you can declare a Module, instead of a class:

<aircode>
Module L3Global
Private mConnection As OleDBConnection

Public Function ConnectDB() As OleDBConnection
If mConnection Is Nothing Then
Dim ConText As String = "Your connection string"
mCOnnection = New OleDBConnectins(ConText)
End If
Return mConnection
End Function
End Module
</aircode>

And then, in your Forms you'd have:

Dim ConnL3Producer _
As OleDbConnection = L3Global.ConnectDB()

Improvise over that.

Regards,

Branco.


Dec 17 '06 #11
Tom,

I hope to disappoint you, however it seems that C# programmers cannot stand
the word "module".

However a singleton C# class is as far as I know nothing more than a module,
which residence at the stack.

Beside the slight misbehaviour that a variable declared in a module can be
called in VB.Net without its module name, is in my idea the module much
nicer for declaring and using shared parts in a program.

I would never write, "Never use a module", I agree with you when it becomes.
"Try to avoid a module, static class, singleton, shared class or whatever
you name them."

Cor

"Tom Leylan" <tl*****@nospam.netschreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
Anil: Yes you can read it right here :-) Never use a module!

VB.Net is an object-oriented language and by definition that should lead
to object-oriented solutions. If there is no OOP solution (and that would
seem unlikely given apps written in SmallTalk, C++, Java, C# and all the
other OOP-based languages) then one might find themselves forced into
having to resort to a "hack". Take my word for it don't start with the
"hack" or you will never stop applying hacks. People will stare at your
code and giggle behind your back...

What you are describing isn't a "module" you are describing a Singleton
Class. If you want to read something perhaps about the Singleton Class
would be a good start.

Try it you may like it.

"Anil Gupte" <an*******@icinema.comwrote in message
news:OC**************@TK2MSFTNGP03.phx.gbl...
>Thanx, that will get me started. Do you happen to know any place where I
can read more about when to use a Module and when to use a class?

Thanx again,
--
Anil Gupte
www.keeninc.net
www.icinema.com

"Branco Medeiros" <br*************@gmail.comwrote in message
news:11**********************@n67g2000cwd.googleg roups.com...
>>Anil Gupte wrote:
I am trying to set up a function that connects to the database that I
can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
<snip>

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each
form?
That defeats the purpose, because each one opens a new connection. How
can
I use this connection object in all my forms but open it only once?
Ideally
I would like to move as much of the intialization (creating the
OLEDBAdapter
etc) to the global routine.
<snip>

I guess you can declare a Module, instead of a class:

<aircode>
Module L3Global
Private mConnection As OleDBConnection

Public Function ConnectDB() As OleDBConnection
If mConnection Is Nothing Then
Dim ConText As String = "Your connection string"
mCOnnection = New OleDBConnectins(ConText)
End If
Return mConnection
End Function
End Module
</aircode>

And then, in your Forms you'd have:

Dim ConnL3Producer _
As OleDbConnection = L3Global.ConnectDB()

Improvise over that.

Regards,

Branco.



Dec 17 '06 #12
Hi Cor (and Dennis):

A quick search of newsgroup messages reveals that similar conversations have
taken place before. One in particular involved Kevin Spencer explaining why
the VB Module exists (backwards compatibility) and offering his opinion that
it should have been removed. I agree with him.

While it may constitute "a class with static properties and no constructor"
I see no reason to provide a second syntax for creating such a thing. Why
not a third or fourth syntax as well? I really don't want to rehash all the
points because for every point made there will be a counterpoint and we
simply duplicate countless other threads.

I would hesitate to describe it as a Singleton class however. There is in
fact a single object in a Singleton class and all properties do not need to
be static. The instantiation of that object can be delayed until "first
use". One can obtain a reference to the singleton object which can be
passed as a parameter to other methods. If these things can be done with
the VB module that's cool but again I ask why do we need two ways to obtain
identical results? Furthermore we cannot create a singleton class using
Module syntax subclassed from an arbitrary class right? So it is not only a
"dupe" it is a limited use duplication.

I believe it comes down to clarity of design. I can't explain it better but
we don't need a language to implement every person's favorite way to do
something. If anybody wants "module" functionality couldn't they simply
declare a class in the way that the module does and get it? There it is,
available to anybody who wants it, not part of the official language syntax,
not misinterpreted as being a VB feature, etc.

Cor, you're misinterpreting or simply guessing. It isn't that C#
programmers can or cannot stand the word module. A C programmer doesn't
think more clearly than a VB programmer, a dBASE programmer doesn't rank
somewhere in a good programmer chart. There are good and bad (shall we call
them neat and sloppy) programmers using every language. There is often a
division between people who love having "&" and "+" available to concatenate
strings and those who ask, why two operators? Some may find two ways "a
brilliant design" while others will say it creates unnecessary ambiguity. I
wouldn't say that C# developers find it odd and VB developers find it cool.

The VB module doesn't add anything to the language (that I am aware of) and
as such it should be removed from the language.
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2******************@TK2MSFTNGP06.phx.gbl...
Tom,

I hope to disappoint you, however it seems that C# programmers cannot
stand the word "module".

However a singleton C# class is as far as I know nothing more than a
module, which residence at the stack.

Beside the slight misbehaviour that a variable declared in a module can be
called in VB.Net without its module name, is in my idea the module much
nicer for declaring and using shared parts in a program.

I would never write, "Never use a module", I agree with you when it
becomes. "Try to avoid a module, static class, singleton, shared class or
whatever you name them."

Cor

"Tom Leylan" <tl*****@nospam.netschreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
>Anil: Yes you can read it right here :-) Never use a module!

VB.Net is an object-oriented language and by definition that should lead
to object-oriented solutions. If there is no OOP solution (and that
would seem unlikely given apps written in SmallTalk, C++, Java, C# and
all the other OOP-based languages) then one might find themselves forced
into having to resort to a "hack". Take my word for it don't start with
the "hack" or you will never stop applying hacks. People will stare at
your code and giggle behind your back...

What you are describing isn't a "module" you are describing a Singleton
Class. If you want to read something perhaps about the Singleton Class
would be a good start.

Try it you may like it.

"Anil Gupte" <an*******@icinema.comwrote in message
news:OC**************@TK2MSFTNGP03.phx.gbl...
>>Thanx, that will get me started. Do you happen to know any place where
I can read more about when to use a Module and when to use a class?

Thanx again,
--
Anil Gupte
www.keeninc.net
www.icinema.com

"Branco Medeiros" <br*************@gmail.comwrote in message
news:11**********************@n67g2000cwd.google groups.com...
Anil Gupte wrote:
I am trying to set up a function that connects to the database that I
can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
<snip>

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global
>
and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection
>
ConnL3Producer = L3G.SetDBConnect
>
The problem is, do I have to setup an instance of L3Global in each
form?
That defeats the purpose, because each one opens a new connection.
How can
I use this connection object in all my forms but open it only once?
Ideally
I would like to move as much of the intialization (creating the
OLEDBAdapter
etc) to the global routine.
<snip>

I guess you can declare a Module, instead of a class:

<aircode>
Module L3Global
Private mConnection As OleDBConnection

Public Function ConnectDB() As OleDBConnection
If mConnection Is Nothing Then
Dim ConText As String = "Your connection string"
mCOnnection = New OleDBConnectins(ConText)
End If
Return mConnection
End Function
End Module
</aircode>

And then, in your Forms you'd have:

Dim ConnL3Producer _
As OleDbConnection = L3Global.ConnectDB()

Improvise over that.

Regards,

Branco.



Dec 17 '06 #13
Tom,

A class in OOP has to be instanced, (you wrote it in my idea yourself) so
that it can sit on the heap. You are true that I am guessing that a
Singleton Class is doing the same as a so called not official existing
Static Class in C# does, I could not yet find it where it residence, so I
should not have written that. There are differences in with the VB Module
and the Singleton, however as much as the behaviour between + and $
concationation in VB.

I like however the name "Module". It makes it for me very clear, that a
module is not a class, it is a part of the main object as it is fixed in the
program. An instances object however sits on the managed heap and will be as
as soon as that is possible removed. I find this name Module therefore nicer
than any Shared/Static class, which is in fact no class in the OOP meaning.

It is possible to write a Module in the same way as a class, and be than not
forced to use the Shared keyword. In a very short discussion between Kevin
Spencer and me about this (with a very small sample from me) he somewhere
wrote a relative short while ago something in these newsgroups as. "You are
right Cor, I did not know this behaviour from the Module". However, to
search special messages on Google from either Kevin or me is not easy.

Cor
"Tom Leylan" <tl*****@nospam.netschreef in bericht
news:eZ**************@TK2MSFTNGP02.phx.gbl...
Hi Cor (and Dennis):

A quick search of newsgroup messages reveals that similar conversations
have taken place before. One in particular involved Kevin Spencer
explaining why the VB Module exists (backwards compatibility) and offering
his opinion that it should have been removed. I agree with him.

While it may constitute "a class with static properties and no
constructor" I see no reason to provide a second syntax for creating such
a thing. Why not a third or fourth syntax as well? I really don't want
to rehash all the points because for every point made there will be a
counterpoint and we simply duplicate countless other threads.

I would hesitate to describe it as a Singleton class however. There is in
fact a single object in a Singleton class and all properties do not need
to be static. The instantiation of that object can be delayed until
"first use". One can obtain a reference to the singleton object which can
be passed as a parameter to other methods. If these things can be done
with the VB module that's cool but again I ask why do we need two ways to
obtain identical results? Furthermore we cannot create a singleton class
using Module syntax subclassed from an arbitrary class right? So it is
not only a "dupe" it is a limited use duplication.

I believe it comes down to clarity of design. I can't explain it better
but we don't need a language to implement every person's favorite way to
do something. If anybody wants "module" functionality couldn't they
simply declare a class in the way that the module does and get it? There
it is, available to anybody who wants it, not part of the official
language syntax, not misinterpreted as being a VB feature, etc.

Cor, you're misinterpreting or simply guessing. It isn't that C#
programmers can or cannot stand the word module. A C programmer doesn't
think more clearly than a VB programmer, a dBASE programmer doesn't rank
somewhere in a good programmer chart. There are good and bad (shall we
call them neat and sloppy) programmers using every language. There is
often a division between people who love having "&" and "+" available to
concatenate strings and those who ask, why two operators? Some may find
two ways "a brilliant design" while others will say it creates unnecessary
ambiguity. I wouldn't say that C# developers find it odd and VB
developers find it cool.

The VB module doesn't add anything to the language (that I am aware of)
and as such it should be removed from the language.
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2******************@TK2MSFTNGP06.phx.gbl...
>Tom,

I hope to disappoint you, however it seems that C# programmers cannot
stand the word "module".

However a singleton C# class is as far as I know nothing more than a
module, which residence at the stack.

Beside the slight misbehaviour that a variable declared in a module can
be called in VB.Net without its module name, is in my idea the module
much nicer for declaring and using shared parts in a program.

I would never write, "Never use a module", I agree with you when it
becomes. "Try to avoid a module, static class, singleton, shared class or
whatever you name them."

Cor

"Tom Leylan" <tl*****@nospam.netschreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
>>Anil: Yes you can read it right here :-) Never use a module!

VB.Net is an object-oriented language and by definition that should lead
to object-oriented solutions. If there is no OOP solution (and that
would seem unlikely given apps written in SmallTalk, C++, Java, C# and
all the other OOP-based languages) then one might find themselves forced
into having to resort to a "hack". Take my word for it don't start with
the "hack" or you will never stop applying hacks. People will stare at
your code and giggle behind your back...

What you are describing isn't a "module" you are describing a Singleton
Class. If you want to read something perhaps about the Singleton Class
would be a good start.

Try it you may like it.

"Anil Gupte" <an*******@icinema.comwrote in message
news:OC**************@TK2MSFTNGP03.phx.gbl...
Thanx, that will get me started. Do you happen to know any place where
I can read more about when to use a Module and when to use a class?

Thanx again,
--
Anil Gupte
www.keeninc.net
www.icinema.com

"Branco Medeiros" <br*************@gmail.comwrote in message
news:11**********************@n67g2000cwd.googl egroups.com...
Anil Gupte wrote:
>I am trying to set up a function that connects to the database that I
>can
>then use gloablly. I set up a class called L3Global in which I have
>a
>function as follows:
>
>Public Function SetDBConnect()
<snip>
>
>Now I want to use this is all my forms (MDI). I set up
>Public L3G As New L3Global
>>
>and then under the approporate button click I have:
>Dim ConnL3Producer As New OleDbConnection
>>
>ConnL3Producer = L3G.SetDBConnect
>>
>The problem is, do I have to setup an instance of L3Global in each
>form?
>That defeats the purpose, because each one opens a new connection.
>How can
>I use this connection object in all my forms but open it only once?
>Ideally
>I would like to move as much of the intialization (creating the
>OLEDBAdapter
>etc) to the global routine.
<snip>
>
I guess you can declare a Module, instead of a class:
>
<aircode>
Module L3Global
Private mConnection As OleDBConnection
>
Public Function ConnectDB() As OleDBConnection
If mConnection Is Nothing Then
Dim ConText As String = "Your connection string"
mCOnnection = New OleDBConnectins(ConText)
End If
Return mConnection
End Function
End Module
</aircode>
>
And then, in your Forms you'd have:
>
Dim ConnL3Producer _
As OleDbConnection = L3Global.ConnectDB()
>
Improvise over that.
>
Regards,
>
Branco.
>




Dec 18 '06 #14
Tom,

My expection that the Singleton is not instanced but seats on the Main part
is that it is in my eyes very inefficient to do it in another way if it has
to be forever in a program.

Cor

"Cor Ligthert [MVP]" <no************@planet.nlschreef in bericht
news:eM**************@TK2MSFTNGP02.phx.gbl...
Tom,

A class in OOP has to be instanced, (you wrote it in my idea yourself) so
that it can sit on the heap. You are true that I am guessing that a
Singleton Class is doing the same as a so called not official existing
Static Class in C# does, I could not yet find it where it residence, so I
should not have written that. There are differences in with the VB Module
and the Singleton, however as much as the behaviour between + and $
concationation in VB.

I like however the name "Module". It makes it for me very clear, that a
module is not a class, it is a part of the main object as it is fixed in
the program. An instances object however sits on the managed heap and will
be as as soon as that is possible removed. I find this name Module
therefore nicer than any Shared/Static class, which is in fact no class in
the OOP meaning.

It is possible to write a Module in the same way as a class, and be than
not forced to use the Shared keyword. In a very short discussion between
Kevin Spencer and me about this (with a very small sample from me) he
somewhere wrote a relative short while ago something in these newsgroups
as. "You are right Cor, I did not know this behaviour from the Module".
However, to search special messages on Google from either Kevin or me is
not easy.

Cor
"Tom Leylan" <tl*****@nospam.netschreef in bericht
news:eZ**************@TK2MSFTNGP02.phx.gbl...
>Hi Cor (and Dennis):

A quick search of newsgroup messages reveals that similar conversations
have taken place before. One in particular involved Kevin Spencer
explaining why the VB Module exists (backwards compatibility) and
offering his opinion that it should have been removed. I agree with him.

While it may constitute "a class with static properties and no
constructor" I see no reason to provide a second syntax for creating such
a thing. Why not a third or fourth syntax as well? I really don't want
to rehash all the points because for every point made there will be a
counterpoint and we simply duplicate countless other threads.

I would hesitate to describe it as a Singleton class however. There is
in fact a single object in a Singleton class and all properties do not
need to be static. The instantiation of that object can be delayed until
"first use". One can obtain a reference to the singleton object which
can be passed as a parameter to other methods. If these things can be
done with the VB module that's cool but again I ask why do we need two
ways to obtain identical results? Furthermore we cannot create a
singleton class using Module syntax subclassed from an arbitrary class
right? So it is not only a "dupe" it is a limited use duplication.

I believe it comes down to clarity of design. I can't explain it better
but we don't need a language to implement every person's favorite way to
do something. If anybody wants "module" functionality couldn't they
simply declare a class in the way that the module does and get it? There
it is, available to anybody who wants it, not part of the official
language syntax, not misinterpreted as being a VB feature, etc.

Cor, you're misinterpreting or simply guessing. It isn't that C#
programmers can or cannot stand the word module. A C programmer doesn't
think more clearly than a VB programmer, a dBASE programmer doesn't rank
somewhere in a good programmer chart. There are good and bad (shall we
call them neat and sloppy) programmers using every language. There is
often a division between people who love having "&" and "+" available to
concatenate strings and those who ask, why two operators? Some may find
two ways "a brilliant design" while others will say it creates
unnecessary ambiguity. I wouldn't say that C# developers find it odd and
VB developers find it cool.

The VB module doesn't add anything to the language (that I am aware of)
and as such it should be removed from the language.
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2******************@TK2MSFTNGP06.phx.gbl. ..
>>Tom,

I hope to disappoint you, however it seems that C# programmers cannot
stand the word "module".

However a singleton C# class is as far as I know nothing more than a
module, which residence at the stack.

Beside the slight misbehaviour that a variable declared in a module can
be called in VB.Net without its module name, is in my idea the module
much nicer for declaring and using shared parts in a program.

I would never write, "Never use a module", I agree with you when it
becomes. "Try to avoid a module, static class, singleton, shared class
or whatever you name them."

Cor

"Tom Leylan" <tl*****@nospam.netschreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl.. .
Anil: Yes you can read it right here :-) Never use a module!

VB.Net is an object-oriented language and by definition that should
lead to object-oriented solutions. If there is no OOP solution (and
that would seem unlikely given apps written in SmallTalk, C++, Java, C#
and all the other OOP-based languages) then one might find themselves
forced into having to resort to a "hack". Take my word for it don't
start with the "hack" or you will never stop applying hacks. People
will stare at your code and giggle behind your back...

What you are describing isn't a "module" you are describing a Singleton
Class. If you want to read something perhaps about the Singleton Class
would be a good start.

Try it you may like it.

"Anil Gupte" <an*******@icinema.comwrote in message
news:OC**************@TK2MSFTNGP03.phx.gbl...
Thanx, that will get me started. Do you happen to know any place
where I can read more about when to use a Module and when to use a
class?
>
Thanx again,
--
Anil Gupte
www.keeninc.net
www.icinema.com
>
"Branco Medeiros" <br*************@gmail.comwrote in message
news:11**********************@n67g2000cwd.goog legroups.com...
>Anil Gupte wrote:
>>I am trying to set up a function that connects to the database that
>>I can
>>then use gloablly. I set up a class called L3Global in which I have
>>a
>>function as follows:
>>
>>Public Function SetDBConnect()
><snip>
>>
>>Now I want to use this is all my forms (MDI). I set up
>>Public L3G As New L3Global
>>>
>>and then under the approporate button click I have:
>>Dim ConnL3Producer As New OleDbConnection
>>>
>>ConnL3Producer = L3G.SetDBConnect
>>>
>>The problem is, do I have to setup an instance of L3Global in each
>>form?
>>That defeats the purpose, because each one opens a new connection.
>>How can
>>I use this connection object in all my forms but open it only once?
>>Ideally
>>I would like to move as much of the intialization (creating the
>>OLEDBAdapter
>>etc) to the global routine.
><snip>
>>
>I guess you can declare a Module, instead of a class:
>>
><aircode>
> Module L3Global
> Private mConnection As OleDBConnection
>>
> Public Function ConnectDB() As OleDBConnection
> If mConnection Is Nothing Then
> Dim ConText As String = "Your connection string"
> mCOnnection = New OleDBConnectins(ConText)
> End If
> Return mConnection
> End Function
> End Module
></aircode>
>>
>And then, in your Forms you'd have:
>>
> Dim ConnL3Producer _
> As OleDbConnection = L3Global.ConnectDB()
>>
>Improvise over that.
>>
>Regards,
>>
>Branco.
>>
>
>




Dec 18 '06 #15

Tom Leylan wrote (inline):
Anil: Yes you can read it right here :-) Never use a module!
I wouldn't go as far as to recommend to *never* use a module. There are
times when the extra syntax needed to create a module-like class just
gets in the way. VB gives you the tools and a Module is just one of
them. Understand it and use it.
VB.Net is an object-oriented language and by definition that should lead to
object-oriented solutions. If there is no OOP solution (and that would seem
unlikely given apps written in SmallTalk, C++, Java, C# and all the other
OOP-based languages) then one might find themselves forced into having to
resort to a "hack". Take my word for it don't start with the "hack" or you
will never stop applying hacks. People will stare at your code and giggle
behind your back...
Yep, the C# 2.0 folks would do that, allright. They'd say "Look, they
call static classes a 'module'!". =)))

BTW, C++ folks may also be intrigued by why are we using such an arcane
construct, cause 99% of the C++ coders I know write OOP-only code...
oops, sorry, I guess I got these stats reversed.
What you are describing isn't a "module" you are describing a Singleton
Class. If you want to read something perhaps about the Singleton Class
would be a good start.
No arguing about that... =)

One of the ways to provide singleton-like functionality is to hide the
actual singleton inside a, uh, module, and provide only controlled
access to it through the methods of the module. Of course, you may
approach singletons however you like. Unfortunately, IMHO, the
SomeClassWithPrivateConstructor.CreateInstance() approach to
singletons, besides tasting much like Java, lacks the clarity of the
good old "New Someclass()".

Regards,

Branco.

Dec 18 '06 #16
Hi Branco:

"Branco Medeiros" <br*************@gmail.comwrote in message
news:11**********************@j72g2000cwa.googlegr oups.com...
>
Tom Leylan wrote (inline):
>Anil: Yes you can read it right here :-) Never use a module!

I wouldn't go as far as to recommend to *never* use a module. There are
times when the extra syntax needed to create a module-like class just
gets in the way. VB gives you the tools and a Module is just one of
them. Understand it and use it.
I'm not arguing mind you but perhaps you could illustrate one of those
times. My point in most of these discussions (regardless of the language)
is to ask why then haven't other languages adopted this really cool thing?
More dramatically if dBASE has a CLEAR ALL command which removes all
variables from memory (and it was a "good" feature rather than a horrid one)
why wouldn't the developers using C, Pascal, VB and such be begging for it?
Yep, the C# 2.0 folks would do that, allright. They'd say "Look, they
call static classes a 'module'!". =)))
This is the part I don't understand. I have static classes in VB and I have
no modules so what am I missing? Why not eliminate the keyword CLASS from
VB and just call them all MODULE? I think it depends upon one's goal and
increasing the differences between languages shouldn't be a goal. If a
keyword is available in C# and in VB I see no reason to change one of them
in an effort to make things harder. I wouldn't add curly braces to VB but I
can't see using new words to describe common concepts. All I'm saying is if
a module is a static class what is the difficulty in calling them a static
class?
One of the ways to provide singleton-like functionality is to hide the
actual singleton inside a, uh, module, and provide only controlled
access to it through the methods of the module. Of course, you may
approach singletons however you like. Unfortunately, IMHO, the
SomeClassWithPrivateConstructor.CreateInstance() approach to
singletons, besides tasting much like Java, lacks the clarity of the
good old "New Someclass()".
You can hide it anywhere you like but I haven't used a single module and I'm
not finding things harder to use or taking longer to write. I don't see the
upside and I see lots of downside to modules. I also don't see anything
wrong (from a language standpoint) with Java. I routinely steal good ideas
from every language I've ever encountered. I also don't use every feature
in a language just because it is available. That VB could reference a
variable without previously declaring it was something it could do but I
have yet to find an example that illustrated why it was needed or should be
used.

I understand that VB supports placing functions in modules, I'm suggesting
(in the long run) it isn't wise to do so.

Most people's mileage is likely to differ :-)



Dec 18 '06 #17
Tom Leylan wrote:
<snip>
There are
times when the extra syntax needed to create a module-like class just
gets in the way.
I'm not arguing mind you but perhaps you could illustrate one of those
times.
I guess this actual thread illustrates such a case.
My point in most of these discussions (regardless of the language)
is to ask why then haven't other languages adopted this really cool thing?
More dramatically if dBASE has a CLEAR ALL command which removes all
variables from memory (and it was a "good" feature rather than a horrid one)
why wouldn't the developers using C, Pascal, VB and such be begging for it?
This is not the point. It seems that every important -- some of them
even cool -- models of computation was already done with by now; modern
language developers are mostly adapting features and stealing sugar.
But languages sometimes don't borrow from one-another even when
something is "cool". Mostly there's a philosophy issue behind the
scenes. Maybe the "stealing" exists, but it's so subtle you can't even
see it's there. How many things Basic (and even VB) stole from Fortran?
How much Java stole from VB? (look very close and you'll see a lot). As
for "clear all", I kinda recall MSX-Basic (from Microsoft breed) had
something like that to clear the garbage collector allocated space,
back in, what, the 80s? C'mon...

I admire people who can code in Perl, and I'm not one of them. Not that
I lack the expertise, mind you, I really believe I can be an
average-to-good programmer in most programming languages (something
laughed here inside myself, but don't listen to it). I don't code in
Perl because the language doesn't appeal to me. VB, on the other side,
is cool in me, and I'm glad Modules have survived the transition to OOP
without becoming a hack. I'd rather declare a Module -- something the
VB programmer will immediatly recognize for what it is -- than to come
up with solutions such as having a shared Singleton() method in a final
class with a private constructor... Not that I'm saying I won't use
that, only that I preffer not to. On the other side, a public
ConnectDB() method inside a module will immediatly make it clear to me
that it's the global scope speaking.

Yep, the C# 2.0 folks would do that, allright. They'd say "Look, they
call static classes a 'module'!". =)))

This is the part I don't understand. I have static classes in VB and I have
no modules so what am I missing? Why not eliminate the keyword CLASS from
VB and just call them all MODULE? I think it depends upon one's goal and
increasing the differences between languages shouldn't be a goal. If a
keyword is available in C# and in VB I see no reason to change one of them
in an effort to make things harder. I wouldn't add curly braces to VB but I
can't see using new words to describe common concepts. All I'm saying is if
a module is a static class what is the difficulty in calling them a static
class?
You're talking about the C# folks, right? Why they didn't call a static
class simply a module, right? Because, AFAIK, the module "concept"
existed in VB long before the C# folks noticed it. Nevertheless, a
couple of most likely reasons to why "static classes" are called Module
in VB: a) because the term "static" in VB has a very specific meaning,
different from the ones it has in C#/C++/Java/C: in such languages,
"static" inside a function declaration means the same as in VB: that
the variable is, er, static (i.e. preserved between calls). Outside a
function declaration, it designate elements shared by all instances of
a class (quite a different meaning, I guess you'll aggree). In VB, by
its turn, a method can be Static, which means that all its internal
variables are static. If you want the C# meaning you must use the term
"Shared". b) because the term "Module" already existed to represent the
exact same thing as C#'s "static class".

To be honest, I'm kinda proud of those keywords that represent
concepts that VB pioneered -- or at least brought to the general
knowledge -- and that were taken hold by other languages, sometimes
having their names changed to cover the evidenc... er, I mean, to suit
the language better, such as For Each, Event (for event-driven
programming), Interface, Module, etc.

This doesn't mean I even *like* those keywords VB invented to represent
concepts already stablished in the programming field (MustInherit and
NotInheritable to name a few).

<snip>
You can hide it anywhere you like but I haven't used a single module and I'm
not finding things harder to use or taking longer to write. I don't see the
upside and I see lots of downside to modules. I also don't see anything
wrong (from a language standpoint) with Java.
Ahw, sure. I just don't sympathize with that guy Scott. Taking that,
Java is ok to me. My point was that there's already A-Way-To-Do-IT (tm)
in VB, I'll use Java's way only if there's no VB way (or if the Java
way is more close to my liking. I'm a bitch, I know).

Notice that Java recently was given Properties, Enums and ForEach, and
two of those were practically born with VB (well, ForEach was born with
Pearl, and Properties were created by TurboPascal, to be exact, but I
doubt they'd have any importance if it wasn't for VB... After all, VB's
ForEach gave headaches to more than one C++ developer when it came to
programming IDispatch interfaces. Now every language demands a foreach
construct, but they should name it "VBForEach", to be honest. Nope,
just kidding, strike that).

<snip>
Most people's mileage is likely to differ :-)
This, I fully aggree.

Regards,

Branco.

Dec 18 '06 #18
responses inline:

"Branco Medeiros" <br*************@gmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
Tom Leylan wrote:
<snip>
There are
times when the extra syntax needed to create a module-like class just
gets in the way.
>I'm not arguing mind you but perhaps you could illustrate one of those
times.

I guess this actual thread illustrates such a case.
I just have to say then that I don't get it. If this thread illustrates an
example where the module is superior then how is every other OOP language
without modules going to do this? And it would seem I couldn't solve the
problem since I'm not going to use a module. Don't you see this thread
doesn't illustrate a great example but rather just "an" example. Nothing
that can't be solved as elegantly using class syntax which already exists.
>My point in most of these discussions (regardless of the language)
is to ask why then haven't other languages adopted this really cool
thing?
More dramatically if dBASE has a CLEAR ALL command which removes all
variables from memory (and it was a "good" feature rather than a horrid
one)
why wouldn't the developers using C, Pascal, VB and such be begging for
it?

This is not the point. It seems that every important -- some of them
even cool -- models of computation was already done with by now; modern
language developers are mostly adapting features and stealing sugar.
But languages sometimes don't borrow from one-another even when
something is "cool". Mostly there's a philosophy issue behind the
scenes. Maybe the "stealing" exists, but it's so subtle you can't even
see it's there. How many things Basic (and even VB) stole from Fortran?
How much Java stole from VB? (look very close and you'll see a lot). As
for "clear all", I kinda recall MSX-Basic (from Microsoft breed) had
something like that to clear the garbage collector allocated space,
back in, what, the 80s? C'mon...
I'm going to guess that fundamentally everything in BASIC came from FORTRAN
via ALGOL. I'd also hazard a guess that virtually nothing from Java was
borrowed from VB. VB wasn't an OOP language and only now rivals Java.
You're mixing up whatever MSX-Basic did with what dBASE languages "do." And
I don't mean in 1980 I mean last week. I sense a "defend VB" thing going on
though, it's a language (an electronic toolset) not a religion.
I admire people who can code in Perl, and I'm not one of them. Not that
I lack the expertise, mind you, I really believe I can be an
average-to-good programmer in most programming languages (something
laughed here inside myself, but don't listen to it). I don't code in
Perl because the language doesn't appeal to me. VB, on the other side,
is cool in me, and I'm glad Modules have survived the transition to OOP
without becoming a hack. I'd rather declare a Module -- something the
VB programmer will immediatly recognize for what it is -- than to come
up with solutions such as having a shared Singleton() method in a final
class with a private constructor... Not that I'm saying I won't use
that, only that I preffer not to. On the other side, a public
ConnectDB() method inside a module will immediatly make it clear to me
that it's the global scope speaking.
That's great and I think we should leave it at that. I'm not a "VB
programmer" I never hope to be one, I have never aspired to be one. I'm a
software developer. Personally I would rather use the ConnectDB() method of
the SQLServer class opening the possibility of my using the ConnectDB()
method of the OracleServer class without modifying a module. Again I
realize to the extreme that VB programmers belong to a cult and to be fair
so do "Java programmers", "SmallTalk programmers" and others who identify
with a toolset. Maybe it's time to start a thread about the best O/S or the
best CPU, it may have been a few days.
Yep, the C# 2.0 folks would do that, allright. They'd say "Look, they
call static classes a 'module'!". =)))

This is the part I don't understand. I have static classes in VB and I
have
no modules so what am I missing? Why not eliminate the keyword CLASS
from
VB and just call them all MODULE? I think it depends upon one's goal and
increasing the differences between languages shouldn't be a goal. If a
keyword is available in C# and in VB I see no reason to change one of
them
in an effort to make things harder. I wouldn't add curly braces to VB
but I
can't see using new words to describe common concepts. All I'm saying is
if
a module is a static class what is the difficulty in calling them a
static
class?

You're talking about the C# folks, right? Why they didn't call a static
class simply a module, right? Because, AFAIK, the module "concept"
existed in VB long before the C# folks noticed it.
Okay thanks... the thread has died.

Dec 18 '06 #19

Tom Leylan wrote (inline):
responses inline:
<snip>
There are
times when the extra syntax needed to create a module-like class just
gets in the way.
I'm not arguing mind you but perhaps you could illustrate one of those
times.
I guess this actual thread illustrates such a case.

I just have to say then that I don't get it. If this thread illustrates an
example where the module is superior then how is every other OOP language
without modules going to do this? And it would seem I couldn't solve the
problem since I'm not going to use a module. Don't you see this thread
doesn't illustrate a great example but rather just "an" example. Nothing
that can't be solved as elegantly using class syntax which already exists.
I never said that this thread illustrates the superiority of modules
over classes. Only that it illustrates, to me, a situation where the
syntax of a module-like class would get in the way, to the point of
making me prefer to use a module instead of the class solution itself.

<snip>
Okay thanks... the thread has died.
Af! Ok, then.

Regards,

Branco.
(gets out musing about language wars, urban religions, cold coffee and
parsing engines)

Dec 19 '06 #20
Branco,

I absolutely do not agree the part that you write about "Static". There is a
static keyword in VB, and that describes what it does (although logically
not technical).

The Shared keyword describes in my idea much better logical what it does
than the Static keyword in C#. In my opinion in the word Static in C# just a
piece of legacy.

Therefore let us not change the facts because the people using C derived
languages tells.

To give an anology: Worldwide Coffee describes much better what we are
drinking than as it is in the jargon from C people.

Java is for me an island from Indonesia. Coffee is a drink from a bean that
long ago was smuggled from Brazil by Dutch people to Java where they started
to cultivate it.

The rest of your text we agree about, but that you knew probably already.

:-)

Just my thought,

Cor
"Branco Medeiros" <br*************@gmail.comschreef in bericht
news:11**********************@n67g2000cwd.googlegr oups.com...
Tom Leylan wrote:
<snip>
There are
times when the extra syntax needed to create a module-like class just
gets in the way.
>I'm not arguing mind you but perhaps you could illustrate one of those
times.

I guess this actual thread illustrates such a case.
>My point in most of these discussions (regardless of the language)
is to ask why then haven't other languages adopted this really cool
thing?
More dramatically if dBASE has a CLEAR ALL command which removes all
variables from memory (and it was a "good" feature rather than a horrid
one)
why wouldn't the developers using C, Pascal, VB and such be begging for
it?

This is not the point. It seems that every important -- some of them
even cool -- models of computation was already done with by now; modern
language developers are mostly adapting features and stealing sugar.
But languages sometimes don't borrow from one-another even when
something is "cool". Mostly there's a philosophy issue behind the
scenes. Maybe the "stealing" exists, but it's so subtle you can't even
see it's there. How many things Basic (and even VB) stole from Fortran?
How much Java stole from VB? (look very close and you'll see a lot). As
for "clear all", I kinda recall MSX-Basic (from Microsoft breed) had
something like that to clear the garbage collector allocated space,
back in, what, the 80s? C'mon...

I admire people who can code in Perl, and I'm not one of them. Not that
I lack the expertise, mind you, I really believe I can be an
average-to-good programmer in most programming languages (something
laughed here inside myself, but don't listen to it). I don't code in
Perl because the language doesn't appeal to me. VB, on the other side,
is cool in me, and I'm glad Modules have survived the transition to OOP
without becoming a hack. I'd rather declare a Module -- something the
VB programmer will immediatly recognize for what it is -- than to come
up with solutions such as having a shared Singleton() method in a final
class with a private constructor... Not that I'm saying I won't use
that, only that I preffer not to. On the other side, a public
ConnectDB() method inside a module will immediatly make it clear to me
that it's the global scope speaking.

Yep, the C# 2.0 folks would do that, allright. They'd say "Look, they
call static classes a 'module'!". =)))

This is the part I don't understand. I have static classes in VB and I
have
no modules so what am I missing? Why not eliminate the keyword CLASS
from
VB and just call them all MODULE? I think it depends upon one's goal and
increasing the differences between languages shouldn't be a goal. If a
keyword is available in C# and in VB I see no reason to change one of
them
in an effort to make things harder. I wouldn't add curly braces to VB
but I
can't see using new words to describe common concepts. All I'm saying is
if
a module is a static class what is the difficulty in calling them a
static
class?

You're talking about the C# folks, right? Why they didn't call a static
class simply a module, right? Because, AFAIK, the module "concept"
existed in VB long before the C# folks noticed it. Nevertheless, a
couple of most likely reasons to why "static classes" are called Module
in VB: a) because the term "static" in VB has a very specific meaning,
different from the ones it has in C#/C++/Java/C: in such languages,
"static" inside a function declaration means the same as in VB: that
the variable is, er, static (i.e. preserved between calls). Outside a
function declaration, it designate elements shared by all instances of
a class (quite a different meaning, I guess you'll aggree). In VB, by
its turn, a method can be Static, which means that all its internal
variables are static. If you want the C# meaning you must use the term
"Shared". b) because the term "Module" already existed to represent the
exact same thing as C#'s "static class".

To be honest, I'm kinda proud of those keywords that represent
concepts that VB pioneered -- or at least brought to the general
knowledge -- and that were taken hold by other languages, sometimes
having their names changed to cover the evidenc... er, I mean, to suit
the language better, such as For Each, Event (for event-driven
programming), Interface, Module, etc.

This doesn't mean I even *like* those keywords VB invented to represent
concepts already stablished in the programming field (MustInherit and
NotInheritable to name a few).

<snip>
>You can hide it anywhere you like but I haven't used a single module and
I'm
not finding things harder to use or taking longer to write. I don't see
the
upside and I see lots of downside to modules. I also don't see anything
wrong (from a language standpoint) with Java.

Ahw, sure. I just don't sympathize with that guy Scott. Taking that,
Java is ok to me. My point was that there's already A-Way-To-Do-IT (tm)
in VB, I'll use Java's way only if there's no VB way (or if the Java
way is more close to my liking. I'm a bitch, I know).

Notice that Java recently was given Properties, Enums and ForEach, and
two of those were practically born with VB (well, ForEach was born with
Pearl, and Properties were created by TurboPascal, to be exact, but I
doubt they'd have any importance if it wasn't for VB... After all, VB's
ForEach gave headaches to more than one C++ developer when it came to
programming IDispatch interfaces. Now every language demands a foreach
construct, but they should name it "VBForEach", to be honest. Nope,
just kidding, strike that).

<snip>
>Most people's mileage is likely to differ :-)

This, I fully aggree.

Regards,

Branco.

Dec 19 '06 #21
Tom,

About your text, I agree with everything you wrote, with one thing you don't
probably agree with me.

VB.Net 2003 is for me the best program development tool I have ever seen.

:-)

Cor
Dec 19 '06 #22

Cor Ligthert [MVP] wrote:
I absolutely do not agree the part that you write about "Static". There is a
static keyword in VB, and that describes what it does (although logically
not technical).
<snip>

Maybe I didn't make it very clear. I was not suggesting another use for
the word "Static". I was actually pointing out that the usual meaning
of the "static" keyword as found in languages such as C# and family is
represented by the "Shared" keyword in VB.

Regards,

Brannco.

Dec 19 '06 #23
Cor,

I routinely rave about how nice it is to develop in Visual Studio. It's a
very productive tool and I'd find it hard to believe some people don't think
so. The problem (as I see it) is usually another form of language wars. A
Java developer may not want to say VS is nice because he can't use it for
development. Not terribly unlike a VB 6 developer talking OOP down or an
early VB.Net developer talking anonymous methods, generics and partial
classes down when they don't have them. VB.Net just got anonymous methods,
Clipper had them 15+ years ago.

I use VB.Net 2005 :-)

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:uD**************@TK2MSFTNGP04.phx.gbl...
Tom,

About your text, I agree with everything you wrote, with one thing you
don't probably agree with me.

VB.Net 2003 is for me the best program development tool I have ever seen.

:-)

Cor

Dec 19 '06 #24

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by David P. Donahue | last post: by
14 posts views Thread by Alan Silver | last post: by
8 posts views Thread by Chattanooga | last post: by
3 posts views Thread by Travis | last post: by
2 posts views Thread by shatemo5 | last post: by
reply views Thread by Fredrik Lundh | last post: by
1 post views Thread by Waqarahmed | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.