Utiliser les différents tests d'égalité

L'égalité stricte compare deux valeurs et teste leur égalité. Aucune des valeurs n'est convertie implicitement en une autre valeur avant que la comparaison soit effectuée. Si les valeurs sont typées différemment, elles sont considérées comme différentes. Si les valeurs sont de même type et ne sont pas des nombres, elles sont considérées égales si elles ont la même valeur. Si les deux valeurs sont des nombres, elles sont égales si elles ont la même valeur et que cette valeur n'est pas NaN ou si l'une vaut +0 et l'autre -0.

var num = 0;
var obj = new String("0");
var str = "0";

console.log(num === num); // true
console.log(obj === obj); // true
console.log(str === str); // true

console.log(num === obj); // false
console.log(num === str); // false
console.log(obj === str); // false
console.log(null === undefined); // false
console.log(obj === null); // false
console.log(obj === undefined); // false

Ce test d'égalité stricte est presque toujours la meilleure des opérations à considérer pour ces tests. Excepté pour les nombres, la sémantique utilisée est simple : une valeur est uniquement égale à elle-même. En ce qui concerne les nombres, il y a deux cas aux limites à considérer. Le premier cas concerne le nombre zéro positif ou négatif. Cela peut être utile dans la représentation de problèmes mathématiques mais ne constitue pas une différence pour de nombreuses situations : le test d'égalité stricte considère que ce sont les mêmes valeurs. Le second cas concerne la valeur « n'est pas un nombre », NaN (pour « not a number » en anglais) permettant de représenter certaines entités mathématiques : la somme des deux infinis (positif et négatif) par exemple. Le test d'égalité stricte considère que NaN est différent de toutes les valeurs, y compris lui-même. (N.B. : Le seul cas de figure pour lequel on a (x !== x) qui renvoie true est lorsque x vaut NaN.)

Le test d'égalité faible compare deux valeurs après les avoir converties en valeurs d'un même type. Une fois converties (la conversion peut s'effectuer pour l'une ou les deux valeurs), la comparaison finale est la même que celle effectuée par ===. L'égalité faible est symétrique : A == B aura toujours la même signification que B == A pour toute valeur de A et B.

La comparaison d'égalité est effectuée comme suit pour des opérandes de différents types :

Dans le tableau ci-dessus, l'expression ToNumber(A) correspond à une tentative de convertir l'argument en un nombre avant la comparaison. Le résultat obtenu est équivalent à +A (l'opérateur unaire +). ToPrimitive(A) correspond à une tentative de convertir l'argument en une valeur primitive grâce à plusieurs méthodes comme A.toString et A.valueOf.

Selon ECMAScript, au sens de l'égalité faible, tous les objets sont différents de undefined et de null. Cependant, la plupart des navigateurs autorisent, dans certains contextes, unensemble restreint d'objets (notamment l'objet document.all), à agir comme s'ils émulaient la valeur undefined. L'égalité faible est un de ces contextes. Pour tous les autres cas, un objet ne sera jamais approximativement égal à undefined ou à null.

var num = 0;
var obj = new String("0");
var str = "0";

console.log(num == num); // true
console.log(obj == obj); // true
console.log(str == str); // true

console.log(num == obj); // true
console.log(num == str); // true
console.log(obj == str); // true
console.log(null == undefined); // true

// Les deux assertions qui suivent sont fausses
// sauf dans certains cas exceptionnels
console.log(obj == null);
console.log(obj == undefined);

Certains développeurs considèrent que ce n'est jamais une bonne idée d'utiliser l'égalilté faible. Le résultat d'une comparaison utilisant l'égalité stricte est plus simple à appréhender et à prédire, de plus il n'y a aucune conversion implicite ce qui rend le test plus rapide.

L'égalité de valeurs répond à un dernier cas d'utilisation : savoir si deux valeurs sont fonctionnellement identiques pour tout contexte. (Ce cas d'utilisation est un exemple du principe de substitution de Liskov). On retrouve ce cas lorsqu'on essaie de changer une propriété immuable :

// Ajouter la propriété immuable NEGATIVE_ZERO au constructor Number.
Object.defineProperty(Number, "NEGATIVE_ZERO", {
  value: -0,
  writable: false,
  configurable: false,
  enumerable: false,
});

function attemptMutation(v) {
  Object.defineProperty(Number, "NEGATIVE_ZERO", { value: v });
}

Object.defineProperty lancera une exception pour tout changement de la propriété qui serait réellement un changement. Rien ne se passera si aucun changement n'est nécessaire. Ainsi, si v vaut -0, aucun changement n'est nécessaire et il n'y aura pas d'erreur. Mais si v vaut +0, Number.NEGATIVE_ZERO n'aurait plus la même valeur immuable. De façon interne à l'implémentation, la nouvelle valeur est comparée avec la valeur courante en utilisant une égalité de valeurs.

L'égalité de valeurs peut être testée grâce à la méthode Object.is.

On utilise la même égalité que l'égalité de valeur et on considère que +0 et -0 sont égaux.

Selon ES5, la comparaison effectuée par == est décrite dans la section 11.9.3 sur l'algorithme d'égalité abstraite (Abstract Equality Algorithm). La comparaison donnée par === est décrite dans la section 11.9.6 sur l'algorithme d'égalité stricte (Strict Equality Algorithm). Ces documents sont en anglais mais sont tout à fait abordables, ne pas hésiter à les consulter (conseil : d'abord commencer par l'algorithme d'égalité stricte). ES5 décrit également, dans la section 9.12 sur l'algorithme SameValue, l'opération utilisée en interne par le moteur JavaScript. Cet algorithme est principalement basé sur l'algorithme d'égalité stricte : 11.9.6.4 et 9.12.4 diffèrent en ce qui concerne les nombres. ES6 (ECMAScript 2015) permet d'utiliser cet algorithme grâce à la méthode Object.is.

Dans ces documents, on peut voir que l'algorithme d'égalité stricte est un sous-ensemble de l'algorithme d'égalité abstraite (exception faite de la vérification du type) car 11.9.6.2–7 correspond exactement à 11.9.3.1.a–f.

Avant ES6 (ECMAScript 2015), il était courant de dire que l'égalité stricte avec le triple égal était une version « améliorée » de l'égalité faible (double égal) et vice versa. En effet, l'égalité faible ajoute une étape de conversion des types qui n'est pas fournie par l'égalité stricte (ce qui permet d'avoir 6 == "6"). On peut aussi dire que l'égalité stricte est une version améliorée de l'égalité simple car elle ajoute une fonctionnalité de vérification des types. Selon votre approche et votre problème, une de ces égalités se prêtera mieux à la résolution.

Cependant, ce « modèle de pensées » ne peut pas être étendu avec l'arrivée d'Object.is avec ES6 (ECMAScript 2015). En effet Object.is() n'est pas plus « faible » que l'égalité faible ou plus « stricte » que l'égalité stricte et il n'est pas non plus quelque part entre les deux. Dans le tableau de comparaison ci-après, on voit que la différence provient avant tout de la façon dont Object.is gère NaN. On note ici que si Object.is(NaN, NaN) valait false, on pourrait dire qu'Object.is() est plus stricte que == ou === car elle distingue -0 et +0. Cependant, ce n'est pas le cas et on a bien Object.is(NaN,NaN) qui vaut true. C'est pour cette raison qu'il faut considérer Object.is selon ses caractéristiques spécifiques plutôt que comme une version plus faible ou plus stricte des autres opérateurs d'égalité.

En plus de la façon dont Object.is traite NaN, la spécificité d'Object.is() réside dans sa façon de traiter les valeurs proches de zéro. Dans des cas d'utilisation où on a besoin d'effectuer de la méta-programmation, notamment pour imiter certaines caractéristiques de Object.defineProperty. Si le scénario d'utilisation ne nécessite pas ce comportement, il est conseillé d'utiliser ===. Même si on souhaite pouvoir comparer NaN avec lui-même et que ce test vaille true, il sera plus simple d'utiliser la méthode isNaN disponible avec les versions antérieures d'ECMAScript. En effet, cela évite d'avoir à traiter des cas plus complexes où il faudrait gérer les signes des zéros dans les différentes comparaisons.

Voici une liste (non exhaustive) d'opérateurs et de méthodes natives qui peuvent entraîner l'apparition des valeurs -0 et +0 dans le code :

- (négation unaire)

Si on prend l'opposé de 0, on aura, bien entendu, -0. Cependant, avec les expressions, cela peut faire que la valeur -0 se glisse dans les variables sans qu'on s'en rende compte. Par exemple :

js

let forceArrêt = obj.masse * -obj.vitesse;

Si obj.vitesse vaut 0 (ou est évalué à 0), un -0 sera introduit, ce qui fera que forceArrêt pourra être négative.

Math.atan2, Math.ceil, Math.pow, Math.round

Ces méthodes peuvent introduire -0 dans une expression lors de leur évaluation, même si -0 ne faisait pas partie des paramètres. Par exemple, si on utilise Math.pow() pour élever -Infinity à une puissance négative, on obtiendra -0 pour une puissance impaire. Pour plus de détails, voir la documentation de chaque méthode.

Math.floor, Math.max, Math.min, Math.sin, Math.sqrt, Math.tan

Ces méthodes peuvent renvoyer -0 dans certains cas où -0 est passé en paramètre. Par exemple, Math.min(-0, +0) fournira -0. Pour plus de détails, voir la documentation de chaque méthode.

~, <<, >>

Chacun de ces opérateurs utilise l'algorithme ToInt32 interne au moteur JavaScript. Étant donné qu'il n'y a qu'une seule représentation pour 0 sur les entiers exprimés avec le type interne sur 32 bits, -0 ne sera pas invariant pour deux opérations symétriques : Object.is(~~(-0), -0) et Object.is(-0 << 2 >> 2, -0) renverront tous les deux false.

Si on utilise Object.is et qu'on ne souhaite pas gérer les cas aux limites autour de zéro, cela peut avoir des effet indésirés. En revanche, si on souhaite effectivement comparer -0 et +0, c'est la méthode à adopter.

• Tableau des comparaisons en JavaScript