>ES3.1 changes the rules to use CreateMutableBinding when entering the
>eval execution context only if x is not already bound, and in any case
>then to call SetMutableBinding (10.2.1.2.3 in the feb09 draft).
>SetMutableBinding calls [[ThrowingPut]]. Strict mode adds value in its
>own way but let's assume it's not used in the following.
[[ThrowingPut]] would not be called in the example given. x has a mutable
binding in a Declarative Environment Record so SetMutableBinding simply records
the value without involving [[ThrowingPut]]. However, the issue Brendan raises
would occur in scenarios where x resolved to a binding in an Object Environment
Record (ie, the global environment or a property of a with bound object). The
same outcome would occur if this global code was executed:
var x = a * a;
eval("function x() { return 'ha ha!'; }");
alert(x);
Brendan actually gets around to saying this but I found it a bit buried in the
message so I wanted to re-emphasize the point that this issue applied only to
globals and with bound names.
I'm not yet convinced that this really is a significant ES3 to ES3.1
compatibility issues. The potential incompatibilities all seem to involve
either side effects of getter/setter properties or explicit attribute
manipulation. Since neither of these are a part of ES3 it would have to be
occurring in existing code using implementation depended means (language
extensions or implementation magic). Code that depended upon such
implementation characteristics would not be portable among ES3 implementations
and hence I don't think there should be expectations that it would be portable
to an conforming ES 3.1 implementation. That said, I do think we want to be
respectful of the existing implementations and not unnecessarily break code
that depends non-standard features in existing ES3 implementations.
I don't see that the specified behavior would be a problem for new code,
written specifically to use ES 3.1 features including accessor properties and
attribute manipulation. I believe that the current ES3.1 draft is complete and
consistent in what will happen when those features are used in conjunction
binding instantiation in Object Environment Records. New code that uses 3.1
features should expect to get 3.1 semantics.
I do think that I could probably fix the concern with some rewriting of 10.6
(Binding Instantiation) and the Environment Record interface/implementation to
ensure that functions get a "fresh" property in the binding objects. However,
I'm reluctant to mess with already "debugged code", ie the specification, at
this point unless this is more than a hypothetical problem.
Can anybody identify any real scenarios based upon existing implementations and
existing code where this change in semantics is actually going to cause a
forward compatibility problem?
Allen
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
