Re: a new proposal for environments

[Pierre-Yves Gérardy <pygy79@...>]

Roberto mentioned a "loadin(env,chunk)" variant, wouldn't that do what you want?
_______________________
Pierre-Yves Gérardy, MD
Headache Research Unit
University of Liege
Citadelle Hospital (University dept. of Neurology),
Boulevard du XIIe de Ligne, 1
B4000 Liège, Belgium
Phone : +32 (0) 4 225 71 41
Mobile : +32 (0) 472 543 727
Fax : +32 (0) 4 223 88 07
Department Secretary : Ms Groven : +32 (0) 4 225 63 91



On Thu, Feb 25, 2010 at 19:40, Jonathan Castello <twisolar@gmail.com> wrote:
> 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
>>
>