Mark S. Miller (2015-01-28T19:16:06.000Z)
On Wed, Jan 28, 2015 at 11:08 AM, Domenic Denicola <d at domenic.me> wrote:

> From: Mark S. Miller [mailto:erights at google.com]
>
> > In this situation, it will try and succeed. This more closely obeys the
> intent in the original code (e.g., the comment in the jQuery code), since
> it creates a non-configurable property on the *Window* W. It does not
> violate any invariant, since all that's observable on the *WindowProxy*
> (given the rest of your draft spec, which remain unchanged) is a
> configurable property of the same name.
>
> Ah, I see! So then another non-intuitive (but invariant-preserving)
> consequence would be:
>
> ```js
> Object.defineProperty(window, "prop", { value: "foo" });
>
> var propDesc = Object.getOwnPropertyDescriptor(window, "prop");
>
> if (propDesc.configurable) {
>   Object.defineProperty(window, "prop", { value: "bar" });
>
>   // this will fail, even though the property is supposedly configurable,
>   // since when it forwards from the WindowProxy `window` to the underlying
>   // Window object, it the Window's [[DefineOwnProperty]] fails.
> }
> ```
>
> Am I getting this right?
>

Exactly, yes. And again, if window is an ES6 proxy rather that a
WindowProxy, it could also cause this behavior, so it doesn't create any
situation which is not otherwise possible.

The key points are:

1) The throw does (arguably) better obey the code's intent, since the
property mostly acts like a non-configurable property until the window is
navigated.

2) If a window navigation happens between your first step and your second,
the second step may well succeed, which is what we (arguably) want, but
which would have been prohibited if propDesc.configurable evaluated to true.


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150128/ba2e7477/attachment.html>
d at domenic.me (2015-02-13T23:27:50.072Z)
On Wed, Jan 28, 2015 at 11:08 AM, Domenic Denicola <d at domenic.me> wrote:

> Am I getting this right?

Exactly, yes. And again, if window is an ES6 proxy rather that a
WindowProxy, it could also cause this behavior, so it doesn't create any
situation which is not otherwise possible.

The key points are:

1. The throw does (arguably) better obey the code's intent, since the
property mostly acts like a non-configurable property until the window is
navigated.

2. If a window navigation happens between your first step and your second,
the second step may well succeed, which is what we (arguably) want, but
which would have been prohibited if propDesc.configurable evaluated to true.
d at domenic.me (2015-02-13T23:27:41.429Z)
On Wed, Jan 28, 2015 at 11:08 AM, Domenic Denicola <d at domenic.me> wrote:

> Am I getting this right?

Exactly, yes. And again, if window is an ES6 proxy rather that a
WindowProxy, it could also cause this behavior, so it doesn't create any
situation which is not otherwise possible.

The key points are:

1) The throw does (arguably) better obey the code's intent, since the
property mostly acts like a non-configurable property until the window is
navigated.

2) If a window navigation happens between your first step and your second,
the second step may well succeed, which is what we (arguably) want, but
which would have been prohibited if propDesc.configurable evaluated to true.