I agree that for a language that will be used for quick programs
( and quick fixes/kludges ) globals are probably essential.
The problem wasn't hard to find. ( Or maybe I should say the problem
wasn't hard to GENERATE - I did have a little trouble FINDING it. )
I was just throwing in one of those quick kludges and adding a global
variable was quicker than rethinking the module interfaces.
However, the process of fixing it ( my program ) left me a bit ambivalent.
I an definitely not a proponent of "straight-jacket" program languages
that make it impossible to do many things in order to keep you from
doing ONE BAD thing. But I'm not against a language that somwhow has
features that encourage you to write GOOD code.
The first fix was that I wrote my globals with "class Global(): pass"
null classes. However, once I got the original to work, I was drawn
to try to OO it a bit more.
I had globals: initial_depth, max_depth and local current_depth, plus
function dir_depth ( just counted the number of "/" in a pathname ).
I now have a half-asses OO version that was just bad enough to show
me the RIGHT way to do it. So I found trying to do without globals
a good learning experience. But probably not one I want to experience
when I'm in a big hurry to "get the damn thing working!"
Anyway:
"global a = 0"
"global b,c "
Can easily be the syntactic shorthand for:
Class __Global__():
pass
__global__ = __Global__()
__global__.a = 0
__global__.b =
__global__.c =
Global to the current module of course.
But access to module.a would be equivalent to module.__global__.a
[ I am here assuming an addition to the symbol table search path. ]
[ BTW Guido - have you ever looked at FORTH dictionaries ?
The syntax of alternate namespaces is awkward in FORTH, but
the dictionaries are tree structured, with the search going
backward from the local leaves to the root ( with side trips
programmable ) so the use of the dictionary search order is
the primary way of managing the namespace. ]
What to do with b,c - that's the rub. Ideally, we would like to
catch the error of access of uninitialized variables. i.e. using
the global value 'b' before an assignment to b should be signaled.
Is there an easy way for it to be know to be a global name and yet
be unbound ?
- Steve
( Again: sorry about the lack of discipline due to the late hour and
a slow modem at home. I meant to indicate that I agreed with the
comment I included above: preponderence of local ref. over global
and of global read ref. over global write ref. , etc. )
======== "If you have a hammer, find a nail" - George Bush,'91 =========
Steven D. Majewski University of Virginia Physiology Dept.
sdm7g@Virginia.EDU Box 449 Health Sciences Center
Voice: (804)-982-0831 1600 Jefferson Park Avenue
FAX: (804)-982-1616 Charlottesville, VA 22908