[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Automatic Variables Local rather than Global (Proposal)
- From: William Willing <william@...>
- Date: Mon, 04 Sep 2006 13:15:14 +0200
Although your proposal makes sense to me where variables are concerned,
I'd be less than thrilled if I had to use it for global functions.
I think a typical scenario - at least in games - is that an application
exposes several global functions to Lua scripts, so scripters can call
these functions to manipulate the state of the application. I wouldn't
be happy if I had to write _G.do_something() everytime I called a global
function, and putting using-statements in every file isn't very
I can understand why you would want variables to be local by default
instead of global and your proposal does have merit; I just don't like
the syntax with _G. as a prefix.
John Hind wrote:
As a long-time user of Lua in an environment where multiple scripters
share a common global table (Girder 4), there is just one thing in Lua
I'd really like to see changed. This is the automatic creation of
variables in the global environment table.
I know there has been discussion of adding an explicit "global"
keyword and an option to switch off automatic variable creation
("option explicit"). I'd like to suggest something slightly different.
My suggestion is that automatic variables should be local rather than
global. To create or reference a global variable you'd have to use the
"_G." prefix which is already available.
Where you currently create a global variable by writing:
x = 1
under my proposal, you'd write:
_G.x = 1
and the first statement would now be equivalent to:
local x; x = 1
This change would be more consistent with the lexical scoping of Lua
and in practical terms would make accidental pollution of the global
table less likely and easier to find using a simple search. It would
also eliminate subtle errors were you think you are accessing a local
variable but in fact are accessing a global with the same name. This
proposal actually simplifies Lua by avoiding the need either for
"local" OR "global" as a keyword.
However, as a separate but related proposal, a "using" keyword might
be desirable - this would specify that, within lexical scope, a
string-keyed table element will be specified using its key alone.
So you could write:
using _G.x; x = 1
This would work with any table, including deeply nested ones, not just
If the first part of this proposal was adopted, transition would
obviously be a problem. I'd suggest overloading the "using" keyword
with "using global" and "using local" to allow specification, within a
chunk, of the automatic variable policy. Anyone embedding Lua would be
able to choose whether to preserve compatibility by making "using
global" the default or to make "using local" the default and force
scripters to change their code.
I really think this would be a big improvement to Lua both
theoretically and practically and worth the undoubted pain of
transition. Any comments?
- John Hind