[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: In praise of globals
- From: Steve Litt <slitt@...>
- Date: Wed, 17 Apr 2013 16:32:59 -0400
On Wed, 17 Apr 2013 11:01:30 +0200
Dirk Laurie <email@example.com> wrote:
> Let us analyze what the suggestion entails. At present, `x=1` means:
> 1. If there is a local variable called `x`, set its value to 1.
> 2. Otherwise, if there is an upvalue called `x`, set its value to
> 1. 3. Otherwise, set _ENV.x to 1.
> The suggestion is to remove Step 3 from the language, and anybody who
> does not like that can compile his own ancient version.
> My point is that removing Step 3 is already possible. In fact, one
> could write functions that control it on a per-variable basis in a
> self-documenting way.
> protect'x,y,z' -- make global x,y,z readonly
> expose'x,y,z' -- make them writeable
> protect('sin,cos,tan',math) -- optional second argument, defaults to
You bring up an interesting point and possibly a "lint utility".
Is there any way to protect every last bit of _ENV? If so, I could run
the program and see every place where a global is being set. Perhaps I
could even protect all of _ENV and then later expose very specific
variables within _ENV. Or, if I were a more freewheeling type of guy,
I'd just comment out the _ENV protection once I knew what was global
and what wasn't.
This would give me immediate feedback when I forget to put in "local x"
and the interpreter doesn't throw a warning.
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance