W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

From: Mark S. Miller <erights@google.com>
Date: Tue, 27 Jan 2015 22:02:49 -0800
Message-ID: <CABHxS9h6ndysah9mNeyt4sdfFpwcHd+8irJoUJXiyanV1xB4Bg@mail.gmail.com>
To: Brendan Eich <brendan@mozilla.org>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Tue, Jan 27, 2015 at 7:22 PM, Brendan Eich <brendan@mozilla.org> wrote:

> Mark S. Miller wrote:
>
>> The reason why the intent is unwarranted is that the descriptor omits
>> "configurable:" rather than explicitly saying "configurable: true". If the
>> owner object already has a configurable own property of the same name, then
>> a defineProperty where the "configurable:" is omitted defines an own
>> property preserving the configurability of the original own property.
>>
>
> Wild, and genius.


(blush)



> How many more narrow escapes can we make and keep both web compat and
> integrity? :-P
>

How many will we need? ;)



>
> Is there any downside? What is the bad case that observably changes
> behavior, if any (not involving proxies)?


You get the following non-intuitive but allowed behavior.

if (!hasOwnProperty(W, P)) {
  defineProperty(W, P, { value: V })
  console.log(getOwnPropertyDescriptor(W, P).configurable); // true
}

However, you could also get this behavior if W is a proxy, so it doesn't
introduce any new cases beyond what's already possible. It is only
surprising.

That's not much of a downside, and I can't think of any other downside.


I'm too tired to search the state space right now, throwing this out as a
> challenge.



-- 
    Cheers,
    --MarkM
Received on Wednesday, 28 January 2015 06:03:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 28 January 2015 06:03:16 UTC