Re: WindowProxy objects violate ES5 invariants

On Thu, Dec 13, 2012 at 11:39 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/13/12 1:50 PM, Boris Zbarsky wrote:
>>
>> On 12/13/12 1:32 PM, Mark S. Miller wrote:
>>>
>>> The invariants say that you cannot claim to be non-configurable and
>>> then have observable changes that should have been possible. The
>>> invariants purposely allow the opposite "violation": a property can
>>> claim to be configurable but still refuse to be configured.
>>
>>
>> Interesting.  That would require some extra magic to keep track of
>> properties that are "really" non-configurable (in terms of behavior)...
>
>
> I've thought about this some more, and here's where I am now:
>
> 1)  UAs need to be able to define non-configurable properties on the
> _Window_.  I don't think there's anything we care about defining on the
> WindowProxy.
>
> 2)  Given that, I think it would be fine to always have WindowProxy throw if
> an attempt is made to define a non-confirable property on it.
>
> 3)  WindowProxy should probably munge the property descriptor for
> non-configurable Window properties to claim they're configurable if it's
> asked.
>
> 4)  Trying to set/define properties on WindowProxy would just forward to the
> Window, modulo #2 above, which would sometimes throw even though the
> property claimed to be configurable.
>
> 5)  Trying to seal/freeze the WindowProxy throws, I guess, possibly after
> doing a seal/freeze on the Window.
>
> This seems like it maintains all the various invariants, right?

>From a quick read, yes. It certainly has the right idea.

>  Is it useful behavior?

Personally, even aside from the immediate issue, I'm skeptical that
these gymnastics between Window and WindowProxy are useful. But I
understand how we got here.

The important point is that it isn't harmful behavior. Most of our
other choices, such as those proposed earlier on this thread, would be
fatal.



>
> -Boris



--
    Cheers,
    --MarkM

Received on Thursday, 13 December 2012 23:08:29 UTC