Re: a new proposal for environments

[Jonathan Castello <twisolar@...>]

I'm also all for making _ENV the new _G. It seems to me that _ENV is
just a generalization of _G, and anything you could do with _G you can
seemingly do with _ENV just the same.

On a related note, could loadstring/loadfile be modified slightly to
load into the currently active environment, rather than their own
environment? If they continue to refer to the original global
environment, then I can't really allow sandboxed code to use them
unless I replace them with my own versions. It seems like a fairly
harmless change, unless people are relying on the load-always-in-_G
behavior.

~Jonathan

On Thu, Feb 25, 2010 at 10:00 AM, Duncan Cross <duncan.cross@gmail.com> wrote:
> On Thu, Feb 25, 2010 at 5:26 PM, Enrico Colombini <erix@erix.it> wrote:
>> David Kastrup wrote:
>>>
>>> Up to now, the difference is quite too much in the "eyes glaze over"
>>> department for my taste.
>>
>> I don't like the idea of reusing the _G name; it could lead to confusion
>> because _G and _ENV are quite different beasts. Consider (5.1):
>
> Yes, but while this is certainly true, for what real-world reason does
> current code change the value of _G? The only one I'm aware of is to
> set it to nil because you don't want people to have an easy reference
> to that table for some reason - but if that's the case, they can just
> use _ENV to refer to it anyway, so you would still need to change your
> code!
>
> I'm all for maintaining back-compatibility whenever appropriate, but
> it just seems like people are worried unnecessarily about technical
> differences between _G and _ENV when the reality is that (a) they seem
> to be there for much the same purpose and (b) pre-5.2 code will
> largely need to be reviewed and re-thought-about anyway. Especially if
> it uses getfenv/setfenv. Also, Roberto mentioned this earlier in the
> thread:
>
>> _ENV = module "libraryname"
>
> ...so presumably every Lua module will need to be changed like this
> before it will work in 5.2. Unless of course module() will still
> change _ENV in the calling script through some trickery?
>
> -Duncan
>