Re: module() with _ENV

[Roberto Ierusalimschy <roberto@...>]

> Hmmm... if that's the case... why not keep setfenv/getfenv and re-implement it in terms of _ENV?
> 
> > (There are some caveats
> > [see message from Mark Hamburg], but it is mostly doable.)
> 
> Are you referring to the, hmm, subtlety about shared _ENV?

Yes, and also about a function not having any _ENV if it does not use
any global variable.


> "If you want to follow the original semantics, it is still possible (mostly), but it is not trivial. "
> 
> http://thread.gmane.org/gmane.comp.lang.lua.general/63344/focus=64190
> 
> That seems a good reason enough (i.e. not trivial) to let
> setfenv/getfenv implement it, no?

If you forget compatibility, I do not see any gain from this extra
complexity. About compatibility, I hope we can implement them in
Lua (using the debug API), so anyone using them could only include
this implementation in his code.


> Also, out of curiosity, what's driving that sudden hatred for
> setfenv/getfenv and the apparent new quest to replace it with these
> various 'in' or '_ENV' or ... proposals?

As already answered, see
http://lua-users.org/lists/lua-l/2010-01/msg00637.html

Refrasing it:

- On one hand, usually a function should not be able to change the
environment of an independent function, as this breaks that function
abstraction. ("usually" meaning "without extra power from the debug
library").

- On the other hand, a function should be able to easily change its own
environment and the environment of the functions it creates.

The _ENV proposal has the big extra benefit that it maps the concept
of environments on top of preexisting and more basic concepts (local
variables), and therefore simplifies the language. It has another
benefit that it is more flexible than setfenv/getfenv.

-- Roberto