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: Brendan Eich <brendan@mozilla.org>
Date: Wed, 28 Jan 2015 11:48:08 -0800
Message-ID: <54C93CF8.4080402@mozilla.org>
To: "Mark S. Miller" <erights@google.com>
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>
Mark S. Miller wrote:
>
>     Exactly correct. I didn't realize until reading your reply is that
>     this is all that's necessary -- that it successfully covers all
>     the cases I was thinking about without any further case division.
>
>
> Here's another option, not clearly better or worse:
>
>
>       [[DefineOwnProperty]] (P, Desc)
>
>  1. let R be the result of calling the [[DefineOwnProperty]] internal
>     method of/W/with arguments/P/and /Desc/.
>  2. If/desc/.[[Configurable]] is present and*false*, then throw
>     a*TypeError*exception.
>  3. return R.
>
> This is exactly like your solution, but with the order of the two 
> steps switched. Perhaps the next breakage we see will tell us which of 
> these to choose. If both are web compatible, then we need only pick 
> which one we like better.

I like the shorter one (filling in from cited text below, here it is in 
full:


      [[DefineOwnProperty]] (P, Desc)

 1. If /desc/.[[Configurable]] is present and/desc/.[[Configurable]] is
    *false*, then throw a *TypeError* exception.
 2. Return the result of calling the [[DefineOwnProperty]] internal
    method of /W/ with arguments /P/ and /Desc/.


Besides being shorter, this doesn't call through to [[DOP]], which could 
have effects, and only then maybe-throw.

/be

>
>         as opposed to the behavior I'd understood we were aiming for,
>         which was:
>
>         1)  If the [[Configurable]] field of Desc is not present or
>         Desc.[[Configurable]] is false, then throw a TypeError exception. 
>
>
>         ?  If so, that's certainly a change that is much more likely
>         to be web-compatible...
>
>
>     Good! It certainly takes care of the one concrete breakage we know
>     about so far.
>
Received on Wednesday, 28 January 2015 19:48:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 28 January 2015 19:48:44 UTC