Is the mutability of bindings in strict eval code observable in the language?

Brendan Eich brendan at mozilla.org
Tue Oct 19 11:08:07 PDT 2010


On Oct 18, 2010, at 10:17 PM, Mark S. Miller wrote:

> On Mon, Oct 18, 2010 at 5:06 PM, Brendan Eich <brendan at mozilla.org> wrote:
> >>>  And since eval code gets its own Lexical Environment, the bindings aren't observable in any code that isn't strict mode.  Is there another way?  Flipping such bindings to be non-configurable would be a nice simplicity win in SpiderMonkey, if it's doable without violating the spec.
> >>
> >> Sounds doable, this was also intentional, IIRC. We really want those strict-eval var bindings not to appear to be properties on any object (so delete does not compute).
> >
> > It's certainly doable.  The question is whether it is incompatible with the spec (ignoring those things like our scope chain being exposed to JSAPI; but we can remove, refactor, deprecate, or obsolete that to eliminate that problem).  I don't see a way that it is, but maybe someone's more observant than me and will see one if I ask.
> 
> The strict-eval-created var bindings should not be subject to delete, or otherwise testable as if [[Configurable]] properties. If this were observable, it would be a flaw in the spec. I don't see it either.
> 
> Suggest you proceed accordingly unless someone on the list, especially Allen or Mark, can show a problem with doing so.
> 
> I'm a little lost. Could someone summarize the question? Thanks.

Sorry, will recap for everyone reading, with spec citations:

In ES5 strict, direct eval of a var declaration (VariableStatement) does not create a binding in the dynamic scope, instead it makes a binding in a new declarative environment isolated to that eval, per ES5 15.1.2.1 and 10.4.2 (step 3 in particular).

So in no case can strict-direct-eval-created vars be considered "configurable" as is the case in ES1-3 (for "configurable" read "lacking DontDelete").

Sorry if this is obvious.

Some implementations still use objects as scope binding frames, even if those objects are not accessible. Such implementations need not make strict-direct-eval-created vars configurable. Better still if they can avoid objects as binding frames!

/be


More information about the es5-discuss mailing list