Cette ligne de Underscore.js qui vérifie l'égalité est-elle vraiment nécessaire ?

Question

Je viens de regarder les _.isEqual de Underscore.js et une section du code ressemble à ceci :

if (a === b) return true;

if (typeof a !== typeof b) return false;

if (a == b) return true;

Je me demande juste s'il y a un cas où la troisième déclaration pourrait être atteinte et évaluée à true ?

Edit : Juste pour être clair, ce n'est pas de mon propre code dont je parle, je lis les sources de Underscore, en particulier, cette ligne et j'étais curieux de savoir pourquoi ils font ça.

Answer 1

Je viens de parcourir le dépôt Underscore et je suis tombé sur une brève discussion où quelqu'un a posé la question suivante exactement la même chose et il semble que ce soit inutile.

En suivant l'algorithme défini par la spécification du langage ECMAScript en section 11.9.6 y section 11.9.3 semble montrer qu'aucune paire de valeurs ne devrait retourner vrai dans le cas ci-dessus.

Donc, en bref, non, cette situation n'est pas possible .

Answer 2

La seule situation dans laquelle == y === réagit de manière inattendue lorsqu'il s'agit de comparer une chaîne littérale ( "123" ) à une chaîne construite ( new String("123") ), ce qui ferait échouer le premier test.

Cependant, lors du deuxième test, il est attrapé parce que la chaîne construite a le type object mais le littéral a le type string .

Sur cette base, je dirais que non, la troisième affirmation ne peut jamais être atteinte, et évaluer à vrai.

Answer 3

Lorsque vous utilisez le == et les expressions sont de types différents, JavaScript convertira généralement les deux dans le même type avant de les comparer.

Par exemple, cela peut se produire avec null y undefined . null == undefined est vrai, même si null === undefined est fausse. Cependant, typeof null es "object" alors que typeof undefined es "undefined" . Donc, dans ce cas, vous devez renvoyer false sur la deuxième instruction.

Vous pouvez lire tous les détails dans la spécification (section 11.9.3), c'est très compliqué : http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

Answer 4

J'ai d'abord pensé qu'il s'agissait de contourner une implémentation défectueuse du navigateur.

Cependant, après avoir fouillé dans les journaux git de ce fichier, il semble que la ligne correspondante se trouvait dans le tout premier fichier underscore.js checkin. (Je ne vais pas chasser dans le documentcloud parent core.js repo...) Vous pouvez le voir à la ligne 334 de https://github.com/documentcloud/underscore/commit/02ede85b539a89a44a71ce098f09a9553a3a6890 .

Je pense donc que c'est juste un morceau qui a été laissé là, qui n'a jamais été testé complètement et qui n'a jamais été nettoyé.