[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Automatic Variables Local rather than Global (Proposal)
- From: "Erik Cassel" <erik@...>
- Date: Wed, 6 Sep 2006 12:29:13 -0700
I get around this problem (partially) by giving every script its own thread
and global table. If some script decides to define a global "i" then it
won't mess up other scripts. Essentially the "global" variable is kept
within the confines of the readable script text.
[mailto:email@example.com] On Behalf Of William Willing
Sent: Monday, September 04, 2006 4:15 AM
To: Lua list
Subject: Re: Automatic Variables Local rather than Global (Proposal)
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