Re: Say No to global-by-default

[Frank Kastenholz <fkastenholz@...>]

It seems to me that the biggest real problem with global-by-default is not actually the globalness of the variables [1] but rather the automatic creation of those variables.  This is what leads to hard to find bugs.  The foo/bar/baz/baa example shows this quite nicely.

One could imagine a mechanism where tables get locked - new keys are not allowed to be added to locked tables, but existing keys could be used in the usual way[2]  One could then further imagine something like
_ENV.global1=...
_ENV.global2=...
_ENV.global3=...
Lock(ENV_)
The foo/bar/baz/baa example would then trigger a LVM error sort of like “attempt to create new key in locked table”

[1] there are other not nice things about globals, such as he performance hit. But those are, I think, manageable. 

[2] this lock would not be a lock in the sense of a data synchronization or mutual exclusion primitive, nor would it be in a security sense. Its goal is for use in eliminating a class of bugs that can be annoying and expensive to find.

That all said, these are all problems with which we have come to understand and live with and have developed various techniques for easing. I have no problems if the PUC-Rio team decide that this is not something that needs changing.

Frank