The global object as the "global scope instance object"
barraclough at apple.com
Sun Jan 22 14:46:41 PST 2012
On Jan 20, 2012, at 4:23 PM, Allen Wirfs-Brock wrote:
> I'm not yet convinced that you need to publicly expose such global object properties accessor properties. I think it is possible to hide the mechanisms.
I'm strongly inclined to agree with this sentiment – engine implementors might choose internally to utilize accessors in their implementations, but from a user perspective it seems to make much more sense that these remain as regular data properties. It is worth bearing in mind that 'const' is already available outside of strict mode and we need to be considerate of any breaking changes we make to existing semantics. (We could define incompatible semantics for strict-mode only, but this would likely lead to a confusing divergence in semantics for users – it could be horribly confusing if const variables in non-strict code were to be implemented as data properties whilst those in strict code were defined as accessor properties).
alert('value' in Object.getOwnPropertyDescriptor(this, 'x'));
alert(Object.getOwnPropertyDescriptor(this, 'x').writable === true);
x = 1;
const x = 2;
x = 3;
This script tests the presence and writability of a property on the global object, and the effect of attempting to assign to it in non-strict code. It demonstrates a non-const var behaving as a regular non-writable property in non-strict code.
On FireFox the above script outputs "true, false, undefined, undefined, 2, 2", which to my mind makes a lot of sense. It perfectly matches, as far as one can test, any other regular non writable property that you could create on an object (of course there it not normally the opportunity to split creation and initialization of a non-writable property).
This behaviour is also sensibly consistent with that for let and var. Running the above script, changing 'const' to 'var' outputs "true, true, undefined, 1, 2, 3" (indicating the property is writable, and all assignments succeed), and for 'let' currently also outputs "true, true, undefined, 1, 2, 3" on FireFox. To my mind this behaviour should probably change slightly. With a temporal dead zone implemented I would expect an attempt to [[DefineOwnProperty]] to an uninitialized value to be rejected (though I would not expect an exception to be thrown from non-strict code) so I would expect the output for 'let' to be "true, true, undefined, undefined, 2, 3" (the assignment of 'a' silently fails leaving the value unchanged).
I would suggest that specifying this as a piece of additional hidden internal state on a data descriptor (rejecting attempts to define or access the value prior to initialization, throwing in strict-mode & silently ignoring in non-strict) makes most sense on a number of grounds:
– compatibility with existing non-strict const implementations.
– consistency with appearance of var properties on the global object.
– consistency with appearance of regular non-writable properties on other objects.
– consistency with behaviour of access to regular non-writable properties on other objects.
– data properties typically have higher performance in implementations, specifying all global let & const properties to be accessors may introduce unnecessary overhead.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss