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

On 1/27/15 4:44 PM, Mark S. Miller wrote:
> Since the WindowProxy is not a Proxy, or more relevantly, even if it
> were a Proxy, the underlying Window is not its target, we can even do
> the following:
>
> When the WindowProxy sees the defineProperty with the omitted
> "configurable:" and determines that the underlying Window does not
> already have this property. WindowProxy can even preserve the
> unwarranted intent expressed in the comment by actually defining a
> *non-configurable* own property on the Window itself. However, the
> behavior of the WindowProxy is not observably different than our Proxy
> example: It acts as if it created a configurable own property on the
> WindowProxy of this same name, and then proceeds with the normal
> defineProperty behavior, which preserves that alleged configurability.

I'd like to understand better the suggestion here, because I'm not sure 
I'm entirely following it.  Specifically, I'd like to understand it in 
terms of the internal methods defined by 
<https://github.com/domenic/window-proxy-spec>.

Presumably you're proposing that we keep all of that as-is except for 
[[DefineOwnProperty]], right?

For [[DefineOwnProperty]], are we basically talking about changing step 
1 to:

1)  If the [[Configurable]] field of Desc is present and 
Desc.[[Configurable]] is false, then throw a TypeError exception.

while keeping everything else as-is, 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...

-Boris

Received on Wednesday, 28 January 2015 01:54:23 UTC