Re: WindowProxy objects violate ES5 invariants

Le 15/12/2012 18:22, Boris Zbarsky a écrit :
> On 12/15/12 12:05 PM, David Bruant wrote:
>> I guess that reveals a different invariant violation :-)
>
> Why?
I thought that having a non-configurable property committed the object 
to keep the property forever, but I can't find back where I read that. 
Maybe I dreamt it?

>> But it creates a violation of ES5, because it means that
>> var/let/const/function global declaration aren't reflected as
>> non-configurable
>
> "reflected"?
In that context, I mean "reported by Object.getOwnPropertyDescriptor". 
You say "reported" below. It's the same idea.

> The section of ES5 in question describes how the properties are 
> created.  That's how they would be created on the Window object: as 
> non-configurable.
>
> If you then ask some _other_ object about those property names, they 
> might get reported as configurable, but I don't see the invariant 
> violation there.
The underlying window may change, but the same WindowProxy object must 
show some consistency. It's the same object (identity equality).

>> I think the solution may just be to reflect as configurable, but act 
>> as if
>> it was non-configurable (and I guess non-writable for "const" 
>> declarations)
>
> That would be the practical upshot of them being actually 
> non-configurable on the Window but the WindowProxy lying about it, yes.
Interesting. That would be an interesting way to think of it from an 
implementation perspective. But as far as authors are concerned, the 
non-[Unforgeable] properties would always be reflected as configurable; 
no way to observe the Window/WindowProxy difference you describe.

David

Received on Saturday, 15 December 2012 17:42:37 UTC