允许重复 属性 名称的目的是什么？

Question

我正在阅读MDN javascript reference，因此下面的代码不再returns false：

function haveES6DuplicatePropertySemantics(){
  "use strict";
  try {
    ({ prop: 1, prop: 2 });

    // No error thrown, duplicate property names allowed in strict mode
    return true;
  } catch (e) {
    // Error thrown, duplicates prohibited in strict mode
    return false;
  }
}

In ECMAScript 5 strict mode code, duplicate property names were considered a SyntaxError. With the introduction of computed property names making duplication possible at runtime, ECMAScript 6 has removed this restriction.

我的问题是，在初始化程序中允许重复的 属性 名称有什么实际好处？我可以看到，当动态分配对象属性时，有时可能会发生这种情况，但由于优先顺序显然决定了哪些属性实际设置在新创建的对象上——这似乎比最好避免的不确定行为更重要。

Answer 1

what are the practical benefits of allowing duplicate property-names in the initializers

没有这样的实际好处。现在 ECMA 脚本 6 中有计算的 属性 键，键的实际值将仅在运行时。实际上，可以在运行时将键添加到对象，它们会覆盖现有的键和值。在 ES-6 中扩展了相同的行为，并且删除了不允许编译时重复键检查的限制。

引用来自 discussion in ESDiscuss Mailing list、

的 Allen Wirfs-Brock

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.

因此，建议保留对普通密钥和 as per this comment the check was dropped later. In Revision 26、

的编译时检查

Eliminated duplicate property name restrictions on object literals and class definitions