Re: Lua locals

[David Jeske <jeske@...>]

On Fri, Nov 14, 1997 at 11:53:51AM -0200, rw20@cornell.edu wrote:
> Hello, again.  Did anyone get my last message about locals?  Sorry to 
> repost if it was just too uninteresting to respond to.
> 
> I'm wondering why Lua defaults to global for variable access in 
> functions.  Most of the time local default is what I need and polluting 
> the global space unintentionally can lead to some difficult bugs.  I know 
> one can just stick a 'local' in front of everything, but one can also 
> program without functons using a goto.

I agree 100%. However, I think the reason things are the way they are is
to preserve the "script like" or "configuration file" like syntax of Lua.
It would be really annoying when using lua to load configuration data to
have to have a ".programrc" file have "global" before every variable.

> I have two suggestions:
> 1.  could some form of fallback govern local vs. global defaults?  this 
> probably isn't the best way.

Actually, this could be quite usefull. Especially combined with a
standard function for requesting context... For example, a configuration
file could just have a bunch of variable sets, and depending on the
current fallback, they would be routes to the appropriate context.
However, one could "use(my_object)" to change the context or something.

You can _almost_ get this behavior right now with the global variable
fallbacks. However, you have no way of knowing what the "current" context
is as far as I know. Not to mention, there is no "standard" way to define
what the current context might be. One person might call the current
context the local variables of a function, while another might refer to a
table (i.e. proto-object) of the method the current context.

I suspect that with a function written in C one could get at the local
variables of the current function (and the arguments). So you could look
at the "self" variable if you want the current context to be the table
(proto-object). If you want it to be the current function's local variable
scope, it is probably a little tricker. ??


Of course "local" would always give you a local variable still.

> 2.  how about a new function declaration keyword, say 'method', which 
> defaults to local access and a new keyword 'global' that gives you access 
> to globals from within functions:
> 	x=10
> 	method test()
> 		print(x)        -- error
> 		x='a string'    -- global x=10 still
> 		print(x)        -- prints 'a string'
>                 print(global x) -- prints 10
> 	end

I would definetly make use of this. However, I can't help but feel perhaps
there is a better way.

-- 
David Jeske (N9LCA) + jeske@chat.net