javascript - 当一个是 bool 值时，为什么 JavaScript 在 == 运算符比较中将原始值转换为数字的基本原理？

Question

我知道规则:

If the two operands are not of the same type, JavaScript converts the operands then applies strict comparison. If either operand is a number or a boolean, the operands are converted to numbers if possible; else if either operand is a string, the other operand is converted to a string if possible.

所以， if("true")通过但 if("true" == true)失败，因为它的句柄类似于 if(NaN == 1) .

当一个值为 bool 值时，我想知道这背后的理性是什么。在其他弱类型语言(如 php)中，这种处理方式不同——如果一个值是 bool 值，另一个值将转换为 bool 值以进行比较(而不是像在 javascript 中那样将两者都转换为数字)。

我假设这个选择是为 == 做出的运算符(operator)慎重考虑。任何人都可以提供合理的为什么这是选择的功能？是否有一个常见的用例被选择来解决？我敢打赌这不仅仅是一个错误。

Answer 1

来自 es-discuss@mozilla.org 邮件列表的 Brendan Eich 做出了非常快速的回复:

考虑 Perl:

$ perl -e 'print 0 == "true";'
1

好吧，基本原理很糟糕——但我在 1995 年 5 月创建了 JS，在 AWK、Perl 4、Python 1.2 (IIRC)、TCL 的阴影下。

我应该比 Perl 更关注 AWK，因为

$ awk 'END {print(0 == "0")}'
1D
$ awk 'END {print(0 == "")}'
0D

在某些方面，JS 的 ==运算符通过转换为 NaN 来拆分 Perl(其中非数字字符串，例如 "true" 转换为 0 )和 AWK(其中只有 "0" 转换为 0 )之间的差异。这样，至少，我们有

js> 0 == ""
true
js> 0 == "true"
false

但完整的事实并不是我在仔细地模仿其他语言。相反，一些致力于在类似 PHP 的服务器 (LiveWire) 中嵌入 JS(然后是“Mocha”)的 Netscapers 想要草率的转换，因此程序员可以匹配 HTTP header 字符串(服务器端)或 HTML 表单字段(客户端)，例如， 404 之类的，没有程序员的显式强制。

但那是 90 年代，我很着急，这些前 Borland Netscapers 坚持不懈。所以，正如我在 Strange Loop last year 所说的那样，“我是个白痴!我给了他们想要的!”

隐式转换是我在 JS 匆忙设计中最大的遗憾，没有之一。甚至包括“与”!

Does anyone know the exact reason the choice was made not to convert to boolean any value compared against a boolean in with the == operator?

一般的想法是较窄的类型应该加宽。因此， true == 1接下来是投影 bool 值 {false, true}到 {0, 1} ，就像在 C++ 中一样。

但为什么不加宽 true到字符串，因为您示例中的另一个操作数是 "true" ?好问题。如果操作数是数字或 bool 值，则将字符串与数字进行比较的偏见源于 HTTP header 和数字字符串 HTML 表单字段用例。再一次，这不是很好的理由，但这就是 JS 的“工作原理”:-|。

您可以在 ECMA-262 版本 5.1 规范、11.9.3 抽象平等比较算法、步骤 6 和 7(根据步骤 4 和 5 阅读)中看到这一点:

4. 如果Type(x) 是Number，Type(y) 是String，则返回比较结果x == ToNumber(y)。
5. 如果Type(x) 是String 并且Type(y) 是Number，则返回比较结果ToNumber(x) == y。
6. 如果 Type(x) 是 bool 值，则返回比较结果 ToNumber(x) == y。
7. 如果 Type(y) 是 Boolean，则返回比较结果 x == ToNumber(y)。

这一切都在一个大的“else 子句中，其中 Type(x) 和 Type(y) 用于 x == y 是不一样的。

抱歉，这里没有智慧的珍珠(原文如此)。除了隐式转换， ==和 !=不要将操作数直接(无中间转换)扩大到可以容纳另一个操作数而不会丢失数据的最窄宽度。这种将字符串缩小为数字只是一个拙劣的做法。

如果我们修复了这个错误，我们仍然有:

0 == "0"
1 == "1"
true != "1"
false != "0"

但我们也会有你的例子想要的:

true == "true"
false != ""

根据我所说的对数字而不是字符串转换的偏好，我们不会有 true == "1"或 false == "0" ，因为它从字符串缩小到数字。确实缩小不会丢失任何位，并且可以加宽 0返回 "0"和 1返回 "1" ，但我的意思是说明从 == 的隐式转换规范中删除所有数字对字符串的偏差会做什么。

这样的更改会破坏网络上的大量代码吗？我敢打赌它会是大笔款项。

有些人认为这个缺陷，除了任何隐式转换之外，都是使用 === 的另一个原因。和 !==总是(因为他们从不皈依)，并且完全避开 ==和 != .其他人不同意(尤其是在测试 x == null 时，这是一种单操作符方式 test x === null || x === undefined )。

由于网络在很大程度上兼容直到非常旧的形式消失，我们被困在 ==和 != ，所以我说学习草率的等式运算符做什么是值得的。这样做之后，在我看来，人们可以在他们获胜的地方使用它们:当您知道操作数是相同类型时，例如
typeof x == "function" ， 等等。 x == null
否则，使用 ===和 !== .

如果操作数是数字或 bool 值，则将字符串与数字进行比较的偏见源于 HTTP header 和数字字符串 HTML 表单字段用例。再一次，这不是很好的理由，但这就是 JS 的“工作原理”:-|。

另一个注意事项:如果任何非数字、非空的字符串到数字的隐式转换尝试抛出一个异常(exception)。

这是 JS 设计中另一个依赖路径的偏见:在 ES3 之前，JS1 或任何 ECMA-262 标准中都没有 try/catch。

缺少异常处理也意味着 undefined被归咎于失踪 obj.foo属性(property)到哪里 obj没有这样的属性。这仍然是咬回，可能与隐式转换咬得一样多或更多 == .它也是 web JS 获胜的“对象检测”模式的基础，它完全击败了我见过的所有其他版本控制方案，尤其是基于显式编号和选择加入的先验方案。

如果我花时间为对象检测添加一个存在运算符，那么人们就可以写

function emulateRequestAnimationFrame(...) {...}
if (!window.requestAnimationFrame?)
  window.requestAnimationFrame = emulateRequestAnimationFrame;

IOW，如果我做了 window.noSuchProperty扔但是 window.noSuchProperty?评估为真值或 false (细节还在待定，参见“fail-fast object destructuring”线程复兴，Nil 的想法)。