Global Functions

[Branco Medeiros]

Re: Global Functions


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
SomeClassWithPr ivateConstructo r.CreateInstanc e() approach to
singletons, besides tasting much like Java, lacks the clarity of the
good old "New Someclass()".

Regards,

Branco.

[Tom Leylan]

Re: Global Functions

Hi Branco:

"Branco Medeiros" <branco.medeiro s@gmail.comwrot e in message
news:1166453209 .535423.269790@ j72g2000cwa.goo glegroups.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
SomeClassWithPr ivateConstructo r.CreateInstanc e() 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 :-)

[Branco Medeiros]

Re: Global Functions

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.

[Tom Leylan]

Re: Global Functions

responses inline:

"Branco Medeiros" <branco.medeiro s@gmail.comwrot e in message
news:1166471796 .055776.180170@ n67g2000cwd.goo glegroups.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.

[Branco Medeiros]

Re: Global Functions


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)

[Cor Ligthert [MVP]]

Re: Global Functions

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" <branco.medeiro s@gmail.comschr eef in bericht
news:1166471796 .055776.180170@ n67g2000cwd.goo glegroups.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.
>

[Cor Ligthert [MVP]]

Re: Global Functions

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

[Branco Medeiros]

Re: Global Functions


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.

[Tom Leylan]

Re: Global Functions

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]" <notmyfirstname @planet.nlwrote in message
news:uDaXpyyIHH A.4848@TK2MSFTN GP04.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