[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Implicit Globals - A compile time solution.
- From: David Given <dg@...>
- Date: Thu, 21 Feb 2008 13:16:15 +0000
-----BEGIN PGP SIGNED MESSAGE-----
John Hind wrote:
> In your example, "n" would now be a local at the outer lexical scope, so all
> the inner references would see it and would therefore *not* create new, more
> local, variables. If you *wanted* to create a more local "n" you'd still have
> to use the local keyword. "global" still refers to the global environment
> table - you can be "more local" but you cannot be "more global", you can only
> be "global".
Oh, I see. You're right, I'd misunderstood you.
However, this still means we end up with the following situation:
a = 1
...56192 lines of code snipped...
for b = 1, 10 do ... end
foo() has it's own local b. Now I change the first line to:
b = 1
...and now foo() is modifying the outer-scope version. In other words,
making a keyword at the beginning of the file causes a semantic change
in the meaning of some code 56193 lines later --- not ideal if you want
Give that your original suggestion was that global-by-default causes
pollution of the global namespace if you forget to declare a variable,
I'd suggest that this approach to local-by-default causes pollution of
the local namespace instead --- which I think is exactly the same problem!
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Wizards get cranky, / Dark days dawn, / Riders smell manky, / The
│ road goes on. / Omens are lowering, / Elves go West; / The Shire needs
│ scouring, / You may as well quest." - John M. Ford
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----