Re: Global Functions

Tech-Archive recommends: Fix windows errors by optimizing your registry

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]" <notmyfirstname@xxxxxxxxx> wrote in message
news:%233D%23WLhIHHA.2456@xxxxxxxxxxxxxxxxxxxxxxx
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" <tleylan@xxxxxxxxxx> schreef in bericht
news:%23GH2CULIHHA.3424@xxxxxxxxxxxxxxxxxxxxxxx
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" <anil-list@xxxxxxxxxxx> wrote in message
news:OCFPtkBIHHA.3676@xxxxxxxxxxxxxxxxxxxxxxx
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" <branco.medeiros@xxxxxxxxx> wrote in message
news:1166131605.256508.207250@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.









.

Quantcast