Re: a new proposal for environments

[Jonathan Castello <twisolar@...>]

Not for files, something that's been mentioned before recently: you'd
have to use the io library explicitly, and you could have any number
of valid reasons to not include that.. But I don't see anything useful
coming out of letting, say, a sandboxed module load things into the
global environment instead of its own.

~Jonathan

2010/2/25 Pierre-Yves Gérardy <pygy79@gmail.com>:
> 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
>>>
>>
>