javascript - 为什么在 ES2015 中将 Object.keys 更改为将原语强制转换为对象？

Question

有谁知道从将基元传递给 Object.keys 时抛出错误到默默地将基元强制转换为对象并返回结果的变化背后的原因？

我不确定是否有人会期望 Object.keys('abc') 返回 [0, 1, 2]，这似乎违反了“不要破坏网络”的首要指令。如果某些网站的代码将对 Object.keys 的调用包装在 try/catch 中以处理调用者错误地传递原语怎么办？

这就是为什么我觉得改变背后必须有一个强有力的理由。如果有人知道这方面的信息，我将非常感兴趣。

Answer 1

我在esdiscuss上找不到关于这个决定的任何提及，所以我只能提供我自己的观点。

正如一位评论者所指出的，这是 ES 2015 中允许更广泛地使用非对象输入的更大趋势的一部分。在 ES 2015 规范中，短语“在以前的版本中，非对象参数总是导致 TypeError 被抛出，”出现在对 Object 上 10 种不同方法的引用中。 .

首先，此更改带来了 Object.keys 的行为与 for-in 的行为一致循环，它总是能够对原语进行操作。考虑到规范已经要求在 Object.keys 之间匹配顺序和 for-in ，需要相同的一组有效操作数似乎不足为奇。

此更改似乎对现有代码几乎无害，同时大大降低了 Object.keys 的脆弱性.即使在您 try catch 的情况下，也很难想象成功的情况 Object.keys执行会导致实际问题。我可以很容易地想象这样的代码:

try {
    var keys = Object.keys(input);
} catch {
    // oops, input was a primitive; call `new [Constructor]` to wrap it
    var keys = Object.keys(
        new input.constructor(input)
    );
}

但这不会在 Object.keys 时中断不会出错；一个成功的Object.keys调用使catch代码已过时。

当然，在某处可能存在这样的代码:

try {
    var keys = Object.keys(input);
} catch {
    // oops, input was a primitive; that unlocks the secret prize
    giveUserAFreePuppy();
}

基本上，通过一个非常愚蠢的例子，我想说的是跳过 catch 的情况。 block 确实是有问题的，因为一些代码的操作似乎太牵强了，破坏这样的代码似乎是一个很小的代价来获得不那么脆弱的 Object.keys功能。