Parity error in 10.2.1.2.2 CreateMutableBinding(N,D) in Object Environment Record

Mark S. Miller erights at google.com
Sun Jun 6 00:50:26 PDT 2010


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100606/26d53cf5/attachment.html>


More information about the es-discuss mailing list