lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


-----Original Message-----
[] 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 
appealing either.

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.

William Willing

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 
> _G.
> 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