[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: '_ENV.foo' mandatory for non-local assignment.
- From: Quae Quack <quae@...>
- Date: Sun, 23 Jan 2011 16:24:36 +1100
2011/1/23 Pierre-Yves Gérardy <email@example.com>:
> There has already been a lot of discussion regarding the default variable
> scope, but I don't think that this idea has been proposed.
> The new _ENV system enables a way to consistently define non-locals
> (hereafter globals) without introducing a 'global' keyword.
> It is a bit clunky, but since using globals is most of the time a bad
> practice, making them stand out isn't a problem IMO.
> Reading globals would remain the same.
> This would allow to remove the 'local' keyword (I know, it's controversial,
> I've read the wiki page . I will address the technical aspects discussed
> Introducing explicit upvalues would allow the same scoping flexibilty as the
> current system, with added clarty.
> This should speed up the compiler a bit, since it wouln't have to check
> whether a variable not declared in a given scope is a global or an upvalue.
> It would also allow to throw a compile time error if an upvalue isn't
> You could still declare locals when needed by assigning 'nil' to them.
> Here are some suggestions for the syntax.
> a,b = nil -- declare the locals at the top of the main block. Only one
> nil is needed for the list.
> function foo ()
> upval a, b = 5, 6 -- upval as keyword. Compile time error if they
> are not found.
> function bar ()
> return upval.b -- shortcut: upval as a pseudotable
> I see on drawback to requiring _ENV.foo for assignement : modules. A naming
> convention could be recommended: '__' as the module table, for example.
> Kind regards,
> -- Pierre-Yves
>  http://lua-users.org/wiki/LocalByDefault
The big objection is having to declare upvalules. You had to do this
in lua4.0; and it was found that the current behavior was much better.