lua-users home
lua-l archive

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


I don't really care about code compatibility -- I'm hacking my own Lua variant to use on this particular project. I don't expect a local-global switch in the official distribution. All I was saying was, in cases like this where a lot of people are trying to make the same modification,
it would be nice to have an easy way to enable/disable a particular change.

Now that I'm thinking about it again, maybe all that's needed is a "patch library" somewhere on the website, where you can d/l source code patches against the official releases.

Back to work,
Jason
379



Russell Y. Webb wrote:

It's starting to become apparent to me that life would be easier if new
variables were
local by default, instead of global.


I too have wished for this (as have several others).  The main problem is
code compatibility and the perception that global-by-default fits better
with Lua's role as a configuration language (in conflict with its role as a
scripting language).

Here's a thought.  How about introducing the key work "global" that for now
does nothing (since that's the default behavior).  That means that new code
can be written with explicit "global" notation (making it clearer in my
estimation) and opens the possibility of having a code base one day that
could without too much pain transition to a local by default rule (though it
might not ever switch over).  Code written entirely in this new style could
run in a modified Lua for those who think that's a feature.  Of course this
new code will not run on old versions of Lua but that's often true with
changes to Lua (like the for loop constructs).

Another route is to disallow assignment to globals without passing through a
function: global("name", new_value).  This can be done today and aside from
making standard Lua code fail its only problem lies in the strange feeling
syntax, but who really needs to write to globals very often anyway?