- From: David Bruant <bruant.d@gmail.com>
- Date: Wed, 19 Dec 2012 17:52:57 +0100
- To: "public-script-coord@w3.org" <public-script-coord@w3.org>, EcmaScript <es-discuss@mozilla.org>
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