允许重复的属性名称的目的是什么？ [英] What's the purpose of allowing duplicate property names?

问题描述

我正在阅读 MDN javascript参考资料，因此以下代码不再返回 false ：

I'm reading the MDN javascript reference, accordingly the following code no longer 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;
  }
}

在ECMAScript 5中严格模式代码，重复的属性名称为
，被认为是一个SyntaxError。通过引入计算属性
名称在运行时可以重复，ECMAScript 6已经删除
这个限制。

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.

我的问题是，在初始化器中允许重复的属性名称有什么实际的好处？我可以看到，如果动态分配对象属性有时会发生这种情况，但是由于优先级顺序显然确定了在新创建的对象上实际设置了哪些属性 - 这似乎比任何类似于无限期行为最好地避免的事情。

My question is, what are the practical benefits of allowing duplicate property-names in the initializers? I can see, how when object properties are assigned dynamically this might sometimes occur, but since order of precedence apparently determines which of the properties is actually set on the newly created object -- this seems more than anything like an indefinite behaviour that's best avoided.

推荐答案

在初始化器中允许复制属性名称的实际好处是什么？

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

没有实际的好处。现在ECMA Script 6中有计算属性键，实际值键只能在运行时确定。就这样，键可以在运行时添加到对象，并覆盖现有的键和值。在ES-6中扩展了同样的行为，并且不允许编译时重复键检查的限制被删除。

There are no practical benefits as such. Now that there are computed property keys in ECMA Script 6, the actual value of the keys will be determined only at the runtime. As it is, keys can be added to objects at runtime and they overwrite the existing key and value. The same behavior is extended in ES-6 and the restriction of not allowing compile time duplicate keys check is removed.

从在ESDiscuss邮件列表中的讨论，

计划一直是对包含计算属性键和当前规范的任何对象文字执行运行时验证。草稿包含用于执行检查的伪代码。但是，错误报告（ https://bugs.ecmascript.org/show_bug.cgi?id=1863 ）指出了当前规格的问题。例如，当前规格抛出错误：

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"]() {}
 });

但不在：

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

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

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

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.

所以，建议是保留正常密钥的编译时间检查和为根据此评论，检查后来被删除。在修订版26 中，

So, the proposal was to retain the compile time check for normal keys and as per this comment the check was dropped later. In Revision 26,

消除对象文字和类定义的重复属性名限制

Eliminated duplicate property name restrictions on object literals and class definitions

这篇关于允许重复的属性名称的目的是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！