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

有谁知道更改的原因，从将基元传递给Object.keys时引发错误，到将基元强制转换为对象并返回结果，是错误的原因？

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

这就是为什么我认为变革背后必须有强有力的理由。如果有人在此方面有一些信息，我将非常感兴趣。

最佳答案

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

正如评论员指出的那样，这是ES 2015更大趋势的一部分，以允许更广泛地使用非对象。在ES 2015规范中，在引用TypeError上的10种不同方法时，会出现短语“在上一版本中，非对象参数始终会引发Object”。

首先，此更改使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块确实是有问题的情况似乎牵强附会，因此，破坏此类代码似乎需要付出很小的代价得到一个较不易碎的Object.keys函数。