Looking at all the uses of this method in the spec., the only situation in non-extended ES5 where the [[DefineOwnProperty]] failure could occur would be for global var or function declarations where the global object has been made non-extensible. Whether the implementation dependent global object can be made non-extensible is itself an interesting questions. However, given that possibility I agree that the final argument to [[defineOwnProperty]] in step of 10.2.1.2.2 should be true rather than false. This is sufficient to take care of all situations that occur in the actual ES5 spec. and is the smallest possible correction. Alternative 2 might be needed if extensions were added to the language that required new uses of Object Environment Records. However, that is an issues for future editions of the specification.
Allen From: [email protected] [mailto:[email protected]] On Behalf Of Mark S. Miller Sent: Sunday, June 06, 2010 12:50 AM To: [email protected]; es-discuss Subject: Parity error in 10.2.1.2.2 CreateMutableBinding(N,D) in Object Environment Record Currently it reads (with emphasis added): 10.2.1.2.2 CreateMutableBinding(N,D) The concrete Environment Record method CreateMutableBinding for object environment records creates in an environment record's associated binding object a property whose name is the String value and initializes it to the value undefined. A property named N must not already exist in the binding object. If Boolean argument D is provided and has the value true the new property's [[Configurable]] attribute is set to true, otherwise it is set to false. 1. Let envRec be the object environment record for which the method was invoked. 2. Let bindings be the binding object for envRec. 3. Assert: The result of calling the [[HasProperty]] internal method of bindings, passing N as the property name, is false. 4. If D is true then let configValue be true otherwise let configValue be false. 5. Call the [[DefineOwnProperty]] internal method of bindings, passing N, Property Descriptor {[[Value]]:undefined, [[Writable]]: true, [[Enumerable]]: true , [[Configurable]]: configValue}, and false as arguments. My concern is that last false. It indicates that if the call to [[DefineOwnProperty]] fails, then it should fail silently rather than throwing a TypeError exception. Given the other text I emphasized above, there must already not be any conflicting property on the bindings object. So the only way [[DefineOwnProperty]] can fail is if the bindings object is non-extensible. When the binding is being created to represent a declaration appearing in strict code, this silent error is clearly wrong. Having participated heavily in the discussion and design of strict mode, I am confident this does not reflect our intent and is simply a mistake. I think we have two choices: 1) We can flip this to be unconditionally true. Since legacy code would never make non-extensible binding objects, this would technically be upwards compatible and would avoid breaking the web. But this behavior would be at odds with other similar non-strict cases. 2) We can add an "S" parameter to CreateMutableBindings according to whether the declaration in question appears in strict code. We would then need to propagate this to callers, of which there are four in 10.5 (Declaration Binding Instantiation) and one in 12.14 (The try Statement). This change would be straightforward. Since implementations are proceeding and the window on correcting errata for the ISO version is closing, we should decide soon. I mildly prefer #2, but I would find either acceptable. If there are no objections, let's decide to do #2. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
