Re: Global Const vs Public Const

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

"Bob Butler" <tiredofit@xxxxxxxxxxx> wrote in message
news:u1RZTnm1GHA.1548@xxxxxxxxxxxxxxxxxxxxxxx
Global wasn't eliminated from forms and classes, it was only ever valid in
BAS modules and always meant 'global to the project'. The meaning and use
has not changed. When Public was added it was given two meanings
depending
on where it was used; part of the public interface of the creatable object
for forms and classes or 'global to the project' in a BAS module. There
was
no need to give Public this dual meaning since the Global keyword already
existed and was handling the one case quite nicely and it only introduced
an
ambiguity when looking at code because now you need to know what kind of
module it is in to know what it means. It would have been much more
consistent to just disallow Public in a BAS module since they can't expose
any public (as in external to the project) interface and keep Global as
the
"correct" way to expose things within the project. It may even have made
more sense to replace Global with 'Friend' in BAS modules since that at
least describes the visibility correctly. Public is just plain wrong.

There is no "dual meaning" to public. In fact it is *far* more consistant to
have one keyword. Public simply means exposed outside the class (or module)
it is contained in. If that module is internal (Friend) such as form then
the member is only exposed within the project. If the class is public to the
project then the member in the class is also accessible outside the project.
In the case of a module, the module is really an internal/friend static
class and public members are hence available within the project. To have a
seperate keyword just for this particular situation would be inconsistant.
Why should a member exposed outside a module which is accessible to the
project be defined differently from a member exposed outside a form which is
also accessible to the same project. Both variables have the same scope so
should not be defined as public and private.

In the ideal world it should be possible to define member variables or
functions as public, friend or private and to be able to define classes or
modules as either public or friend. Classes should be defined as friend not
private as friend means internal to the project.

It helps to think of a standard module as a class which has one global
instance.

Michael


.