domenic at domenicdenicola.com (2013-10-26T03:26:44.842Z)
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:
```js
({get a() {},
get ["a"]() {}
});
```
but not on:
```js
({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:
```js
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.
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131025/a32ca59e/attachment-0001.html>