lua-users home
lua-l archive

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


On Jan 12, 2010, at 3:17 PM, Eike Decker wrote:

> The purpose of this change seems to be to help "normal" people not to
> be confused by the presence of two functions, but effectively, the
> lack of this functionality is an ugly hindrance for clever people who
> know what they are doing.

I'm not sure that you're properly understanding either the consequences or the motivations of the change. Maybe you do, in which case I apologize for any misunderstanding, but let me restate a couple points just to be sure:

The ability for function closures to have different environments is certainly not being removed. If you define a function inside an "in" block, it inherits that block's environment as its own. Functions can absolutely still have different environments for resolving global references.

Roberto has been kind enough to state recently (by starting this thread, in fact) that the intention of the change is not to "simplify" the language but rather to make it easier to establish clear barriers between areas of code that might need them (in the case of the World of Warcraft secure handler sandbox, we needed not only to stop code inside the sandbox from breaking out, but also to stop code outside the sandbox from breaking in; under Lua 5.1, it was necessary to modify the implementations for getfenv and setfenv to enable this security). In most cases, if something wants its environment to be accessible somewhere else, it can still make that information available, just explicitly rather than by relying on the target code to get it itself.

The biggest outcry seems to revolve around dynamically changing a function between different environments while the program is running, and I think it's clear based on the response that some sort of solution is in fact needful in that regard. We've already generated pages of discussion on the matter, from workarounds in pure Lua to changes to the API. What it sounds like we really need to be most productive is input on what the most critical uses are that the lexical environment system doesn't resolve by itself, why the existing workarounds (as several have already been generated) are inadequate, and how to restore those uses without the simple expedient of "bring setfenv back now plz."

NFF