我正在阅读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严格模式代码中,重复的属性名称为 被认为是SyntaxError。随着计算属性的引入 在运行时可以复制的名称,ECMAScript 6已删除 这个限制。
我的问题是,在初始化程序中允许重复的属性名称有什么实际好处?我可以看到,当动态分配对象属性时,有时会发生这种情况,但由于优先顺序显然决定了在新创建的对象上实际设置了哪些属性 - 这似乎不仅仅是最好避免的无限行为。
答案 0 :(得分:19)
在初始化程序中允许重复的属性名称有什么实际好处
没有实际的好处。现在ECMA Script 6中有计算属性键,键的实际值将仅在运行时确定。实际上,可以在运行时将键添加到对象,它们会覆盖现有的键和值。在ES-6中扩展了相同的行为,并且删除了不允许编译时重复键检查的限制。
从discussion in ESDiscuss Mailing list,
引用Allen Wirfs-Brock计划是对包含计算属性键和当前规范的任何对象文字执行运行时验证。 draft包含用于执行检查的伪代码。但是,错误报告(https://bugs.ecmascript.org/show_bug.cgi?id=1863)指出了当前规范的问题。例如,当前的规范。抛出错误:
({get a() {}, get ["a"]() {} });
但不是:
({get ["a"]() {}, get a() {} });
基本上,在处理包含计算键的属性定义时,仅检查已定义的属性键是不够的。如果存在任何计算的密钥,则即使对于具有文字属性名称的定义,也必须进行检查。仅仅考虑属性键和数据/访问器属性的区别是不够的,验证还必须考虑定义的句法形式以及是否适用严格模式 .. < / p>
事实证明,即使在伪代码中,这也是一组相当复杂的运行时验证规则。我很难说服自己,这种动态验证的运行时计算和元数据成本是合理的。它的成本太高,实际效益非常小。
因此,我建议删除对象文字(和类定义)的运行时验证。对于没有计算密钥的属性定义,我们仍然会有静态验证和早期错误。但是任何使它超过这些检查的东西(包括所有具有计算名称的属性定义)都是按顺序处理的,没有重复的名称检查。
因此,提议是保留正常密钥的编译时间检查,并as per this comment稍后删除检查。在Revision 26,
消除了对象文字和类定义的重复属性名称限制