private variables/methods

[Sean Ross]

"Harri Pesonen" <fuerte at sci.fi> wrote in message
news:SMDib.231$8j.6 at reader1.news.jippii.net...
> Christopher Koppler wrote:
> > Hmmm, asking naively: why not make global (or some better name, I
> > don't have any good ideas however) the self of the current module -
> > i.e. instead of
> >
> > def fun():
> >   global x
> >   x = somevalue
> >
> > or your import, you'd use
> >
> > def fun():
> >   global.x = somevalue

Christopher:

Hi.
You couldn't use "global" that way for backwards compatability reasons.
Still, I like the overall idea.

[snip]
> Sounds good to me. So if you have now
>
> a = 1
> def b():
> a = 2
>
> This would cause a compiler warning that a global "a" already exists.


Harri:

Hi.
Actually, I don't think that is what's intended. Rather, if you want to use
the global variable a, you will need to access it through the current module
object, which can be referenced using global, i.e.,

a = 1
def b():
    global.a = 2 # rebinds the global variable a
    a = 3 # binds a new local variable a, the global variable a is
unaffected.
    print "a values: global = %s; local = %s"%(global.a, a)

#output
a values: global = 2; local = 3

the local and global variables a will not be confused, because the global
variable a can only ever be referenced in the local scope via the current
module reference ("global"). Meaning, if you want to use a global variable
in a scope other than at the module level , you'll have to preface it with
"global.".

> So
> the programmer should write either
>
> def b():
> global.a = 2
>
> or
>
> def b():
> local.a = 2
>
> The latter of course creates a new local variable with the same name.
> After this it is OK to use just "a" without "local" prefix?
>
> def b():
> local.a = 2
> a = 3
>

So, continuing from the explanation above, you will not have to say "local.a
= 2" to bind a local variable. All variables will be local by default.
Variables from other namespaces (such as globals) will have to be explicitly
resolved (e.g. "global.a = 2")

> How about the following:
>
> def b():
> global.a = 2
> a = 3
>
> Is the second "a" still global?
>

No.

> The idea with "Option Explicit" gets around this differently. The
> following creates a new local variable:
>
> def b():
> var a = 2
>
> While the following refers to the global variable, if there is no local
> variable with the same name:
>
> def b():
> a = 2
>
> This would be more beautiful.
>

Making a variable local by default, and requiring that globals be accessed
explicitly seems like a better path to me. As far as I know, the use of
globals is generally discouraged. So a lot of people try to avoid using them
in code, when they can. But local variables occur all the time. Using
"Option Explicit" would seem to be making you write more code for something
that happens more often (local variable binding), and less code for
something that is discouraged and should be happening less often (global
variable rebinding).  But maybe thats just me...

Sean