Partial conclusions on WindowProxy and ES5 invariants

Hi,

In this message, I try to capture the conclusions of the couple of 
recent threads that happened regarding WindowProxy and ES5 invariants 
starting [1][2].
I understand the following conclusions:
1) WindowProxy don't allow scripts to set their internal [[Extensible]] 
to false (attempts to do this throw). This one was unambiguous, but 
bares repeating.
2) WindowProxy don't allow the definition of new non-configurable 
properties via Object.defineProperty/defineOwnProperties (attempts to do 
this throw)
3) WindowProxy objects reflect [Unforgeable] properties as own 
configurable getters (properties like 'location' which are also 
[PutForward] also have a setter)
3.1) It does NOT change the semantics of [Unforgeable] for other objects 
(maybe 2 different annotations should be defined to differenciate the 2 
cases)
3.2) There is some ongoing discussion to add new property descriptors 
attributes which would be used only for some objects (like WindowProxy) 
to express that a property is configurable and yet non-deletable using 
the 'delete' operator [3]. Maybe this discussion will lead nowhere, but 
it's worth being followed by anyone interested by WebIDL.
3.3) Brendan Eich noticed that current engines reflect window.location 
as a data property [4]. All of them are expected to change this as soon 
as possible to comply to WebIDL.
4) All other own properties (wherever they're from) are reflected as 
configurable
5) var/function globals are reflected as configurable for WindowProxy 
(ECMAScript is likely to change its definition to still prevent the use 
of 'delete' but let the choice of the configurable value 
implementation-dependent)
6) It's probably a given, but implementations are expected to 
instantiate fresh getters and setters each time navigation occurs in a 
browsing context.

If these partial conclusions are applied, WindowProxy respect ES5 
invariants without making too much trouble or adding too much weirdness.

configurable:true may be felt as not expressive enough, so I encourage 
people on the WebIDL side to participate to the discussion about the 
eventuality to reflect different property descriptor attributes for 
WebIDL objects in cases where it'd be necessary. Or the eventuality to 
reflect this information in other ways if relevant.


Is there a disagreement on these partial conclusions?

Thanks to everyone who participated to these discussions,

David

[1] 
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0322.html
[2] https://mail.mozilla.org/pipermail/es-discuss/2012-December/027080.html
[3] https://mail.mozilla.org/pipermail/es-discuss/2012-December/027223.html
[4] https://mail.mozilla.org/pipermail/es-discuss/2012-December/027145.html

Received on Wednesday, 19 December 2012 16:53:28 UTC