W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Violations of internal method invariants?

From: Tom Van Cutsem <tomvc.be@gmail.com>
Date: Thu, 31 Jul 2014 17:36:24 +0200
Message-ID: <CAKDfNj_F-Fv8_q5sEGm+biby6Zn9F_xBFEzjy5np9EyjTqKckg@mail.gmail.com>
To: Jason Orendorff <jason.orendorff@gmail.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
2014-07-31 15:26 GMT+02:00 Jason Orendorff <jason.orendorff@gmail.com>:

> There's not a rule that says flat-out, "If Desc.[[Configurable]] is
> false and [[DefineOwnProperty]](P, Desc) returns true, that counts as
> 'observing' the property P as a non-configurable property on the
> target." but if you take that as read, what WebIDL is doing here is
> banned.
> Note that steps 14-22 of 9.5.6 (Proxy#[[DefineOwnProperty]]) do some
> checks which enforce this rule.
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-defineownproperty-p-desc
> Tom, can the prose be improved? What's the intent?

The intent is indeed that if [[DefineOwnProperty]] returns true for a
non-configurable descriptor, then the client can count on the property
being defined *as a non-configurable property*. It would not be OK for a
proxy to tamper with the descriptor that the client passed in (e.g. by
coercing configurable to "true") and then signalling success, which seems
to be what WebIDL is doing here.

The prose says: "A property cannot be added as or modified to be
non-configurable, if it does not exists as a non-configurable own property
of the target object."

Possibly we need to make more explicit the fact that "added as
non-configurable" pertains to the original attribute state that the client
passed in.

Received on Thursday, 31 July 2014 15:36:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC