[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: a new proposal for environments
- From: Drake Wilson <drake@...>
- Date: Thu, 25 Feb 2010 03:45:56 -0600
Quoth Alexander Gladysh <firstname.lastname@example.org>, on 2010-02-25 12:06:54 +0300:
> Cool idea. But I have a question.
> So, _ENV is visible to the end-user? Also it is a "special" variable
> (as opposed to _G, which is just good old global).
It's not really a "special" variable. What it means, AIUI, is that
"global variables" as a core semantic element go away, and access to a
"global" becomes syntactic sugar for table access to a specially-named
local (much as how "method call" is not a core semantic element, but
an abbreviation for table access and function call).
This is a huge simplification: it means that the special "environment"
goes away entirely, and its properties are folded into the general
idea of locals (things defined here) and upvalues (things from above).
I approve heartily.
> I'm not sure I like this. Special variables are evil, and I can't
> control them by overriding a couple of functions (or removing them
> from the sandbox).
I assume that the loading of new functions will still allow you to
specify the initial value of _ENV. After that, I'm not sure what
other "control" you want: you have no way to alter the "environment
link" (which is just a local/upvalue now!) of existing functions
except via special debug APIs that can arbitrarily change locals and
upvalues (which can be denied in a sandbox environment). A function
can still "change" its own "environment", but this is no different
semantically than changing any other local variable; a function could
also just retrieve whatever it needs and then ignore _ENV entirely
thereafter (which might often be a good thing anyway).
---> Drake Wilson