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

Question

我正在阅读MDN javascript reference，因此以下代码不再返回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;
  }
}

在 ECMAScript 5 严格模式代码中，重复的属性名称是 被认为是语法错误。随着计算属性的引入 在运行时可以复制的名称，ECMAScript 6 已删除 这个限制。

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

Answer 1

在初始化器中允许重复的属性名有什么实际好处

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

从discussion in ESDiscuss Mailing list 引用 Allen Wirfs-Brock，

计划是对包含计算属性键和当前规范的任何对象文字执行运行时验证。草稿包含进行检查的伪代码。然而，错误报告 (https://bugs.ecmascript.org/show_bug.cgi?id=1863) 指出了当前规范存在的问题。例如，当前的规范。引发错误：

({get a() {},
   get ["a"]() {}
 });

但不在：

({get ["a"]() {},
   get a() {}
 });

基本上，在处理包含计算键的属性定义时，仅检查已定义的属性键是不够的。如果存在任何计算键，则即使对于具有文字属性名称的定义也必须进行检查。仅考虑属性键和数据/访问器属性的区别是不够的，验证还必须考虑定义的句法形式以及是否适用严格模式..

事实证明，即使在伪代码中，这也是一组相当复杂的运行时验证规则。我很难说服自己这种动态验证的运行时计算和元数据成本是合理的。成本太高，实际收益微乎其微。

出于这个原因，我建议我们放弃对对象文字（和类定义）的运行时验证。对于没有计算键的属性定义，我们仍然会有静态验证和早期错误。但是任何通过这些检查的东西（包括所有具有计算名称的属性定义）都只是按顺序处理，没有重复名称检查。

因此，建议保留对普通键的编译时检查，as per this comment 后来取消了检查。在Revision 26，

消除了对对象字面量和类定义的重复属性名称限制