ES5 introduced several rules regarding duplicate in property definitions in an
object literal. The rules are roughly:
You can use the same property name in both a data property definition and
an accessor property definition
You can't define more than one get accessor for a given property name
You can't define more than one set accessor for a given property name
In strict mode, you can't have multiple data property definitions for a
given property name
These rules we designed such that they could be statically checked and reported
as early errors.
These rules also need to be expanded to deal with new property definition
forms. For example, just like you can't use the same name in both a data
property definition and an accessor property definition (in any mode), it
should also be illegal to use the same name in both a data property definition
and a concise method definition or have two concise methods with the same name.
The addition of computed property keys in object literals means that these
conditions cannot be fully statically checked if any of the property
definitions in an object literal has a computed property key.
The plan has been that runtime validation would be performed for any object
literals containing computed property keys and the current spec. draft contains
pseudo code for doing the checks. However a bug report
(https://bugs.ecmascript.org/show_bug.cgi?id=1863 ) points out an issue with
the current spec. For example, the current spec. throws an error on:
({get a() {},
get ["a"]() {}
});
but not on:
({get ["a"]() {},
get a() {}
});
Basically, it isn't sufficient to only check for an already defined property
key when processing property definitions that contains a computed key. If any
computed keys exist the checking has to be done even for the definitions that
have literal property names. And it isn't sufficient to just consider the
property keys and the data/accessor property distinction, the validation also
has to take into account the syntactic form of the definition and whether or
not strict mode applies..
It turns out that even in pseudo code, this is a fairly complicated set of
runtime validation rules to apply. I'm having a hard time convincing myself
that the runtime computational and meta data costs of this dynamic validation
is justified. It costs too much and the actual benefit is pretty small.
***For that reason, I propose that we drop this runtime validation of object
literals (and class definition). We would still have the static validation and
early errors for property definitions that don't have computed keys. But
anything that makes it past those checks (including all property definitions
with computed names) are just processed sequentially with no duplicate name
checking.***
What about predetermining the "shape" of literal objects that include computed
property keys?
One of the reason for the dynamic checks was the desire to preserve the
characteristics that allowed an implementation to look at an object literal and
statically determine exactly how many own properties the resulting objects
would have. The hope was that an implementation could still determine an
intended shape and that the dynamic checks would guarantee that the actual
constructed objects conform to that predicted shape. If we drop the dynamic
checks we loose that shape guarantee.
I think this ability to predict an intended shape was probably a committee
pipe-dream. Consider this function:
function makeObj(a,b,c,d,e) {
return {
get [a] () {},
get [b] () {},
set [c] (v) {},
set [d] (v) {},
set [e] (v) {}
}
}
The object returned by this function might validly have 3, 4, or 5 properties.
The is no clearly intended shape to try to guarantee.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
