[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: Fri, 22 Feb 2008 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
