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);
alert(Object.getOwnPropertyDescriptor(this, 'x').value);
x = 1;
alert(Object.getOwnPropertyDescriptor(this, 'x').value);
const x = 2;
alert(Object.getOwnPropertyDescriptor(this, 'x').value);
x = 3;
alert(Object.getOwnPropertyDescriptor(this, 'x').value);
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.
cheers,
G.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
