RE: Automatic Variables Local rather than Global (Proposal)

["Erik Cassel" <erik@...>]

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.

http://lua-users.org/lists/lua-l/2003-10/msg00269.html


-Erik


-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] 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
>
>