Re: Implicit Globals - A (better?) compile time solution.
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Implicit Globals - A (better?) compile time solution.
- From: "John Hind" <john.hind@...>
- Date: 2008年2月22日 11:32:52 -0000
GregF wrote:
<<
One case I haven't seen yet mentioned in this thread is the following:
do
if test then
a = 1
else
a = 2
end
print(a)
end
which under your proposal would print nil!
It's certainly a matter of opinion, but my opinion is that is quite bad, and
very hard to justify to novice coders.
As has also been mentioned, a=a+1 meaning "create a new local set to 1 more
than the global variable's value" would be quite disorienting as well.
>>
Point taken on the if blocks - this is bad, but IMHO still not *as* bad as
creating a new, late-bound, system wide global which (quietly) stomps on any
other such global with the same name! 'a=a+1' is less of an issue because it
does not make sense unless the programmer knows there is already a
wider-scope 'a'. If she is incrementing a local counter, that counter would
have had to have been initialised (and therefore created) in an earlier
statement.
Here is another attempt at a proposal for improving this which might
actually be original (prove me wrong people!):
How about if automatic variables were created as upvalues of the immediately
enclosing function (or chunk)? This would make them compile-time but with
function-wide scope. I think this might be a good compromise and accord with
the naive expectation about how things should behave.
- John