Pourquoi `null> = 0 && null <= 0` mais pas` null == 0`?

J'ai dû écrire une routine qui incrémente la valeur d'une variable de 1 si son type est numberet affecte 0 à la variable sinon, où la variable est initialement nullou undefined.

La première implémentation était v >= 0 ? v += 1 : v = 0parce que je pensais que tout ce qui n'est pas un nombre rendrait une expression arithmétique fausse, mais c'était faux car il null >= 0est évalué à vrai. Ensuite, j'ai appris qu'il nullse comporte comme 0 et les expressions suivantes sont toutes évaluées à vrai.

• null >= 0 && null <= 0
• !(null < 0 || null > 0)
• null + 1 === 1
• 1 / null === Infinity
• Math.pow(42, null) === 1

Bien sûr, nulln'est pas 0. null == 0est évalué à faux. Cela rend l'expression apparemment tautologique (v >= 0 && v <= 0) === (v == 0)fausse.

Pourquoi est nullcomme 0, bien que ce ne soit pas réellement 0?

Votre vraie question semble être:

Pourquoi:

null >= 0; // true

Mais:

null == 0; // false

Ce qui se passe vraiment, c'est que l' Opérateur Supérieur ou égal ( >=), effectue la coercition de type ( ToPrimitive), avec un type d' indication de Number, en fait tous les opérateurs relationnels ont ce comportement.

nullest traité d'une manière spéciale par l' opérateur égal ( ==). Dans un bref, il ne contraint qu'à undefined:

null == null; // true
null == undefined; // true

Valeur telle que false, '', '0'et []sont soumis à la contrainte de type numérique, tous les contraignent à zéro.

Vous pouvez voir les détails internes de ce processus dans l' algorithme de comparaison d'égalité abstraite et l'algorithme de comparaison relationnelle abstraite .

En résumé:

• Comparaison relationnelle: si les deux valeurs ne sont pas de type String, ToNumberest appelée sur les deux. C'est la même chose que d'ajouter un +devant, qui pour null contraint à 0.

• Comparaison d'égalité: n'appelle que ToNumberles chaînes, les nombres et les booléens.

Je voudrais étendre la question pour améliorer encore la visibilité du problème:

null >= 0; //true
null <= 0; //true
null == 0; //false
null > 0;  //false
null < 0;  //false

Cela n'a tout simplement aucun sens. Comme les langues humaines, ces choses doivent être apprises par cœur.

JavaScript propose des comparaisons strictes et de conversion de type

null >= 0;est vrai mais (null==0)||(null>0)est faux

null <= 0;est vrai mais (null==0)||(null<0)est faux

"" >= 0 est aussi vrai

Pour les comparaisons abstraites relationnelles (<=,> =), les opérandes sont d'abord convertis en primitives, puis du même type, avant comparaison.

typeof null returns "object"

Lorsque le type est un objet, javascript tente de stringifier l'objet (c'est-à-dire null), les étapes suivantes sont suivies ( ECMAScript 2015 ):

1. Si ce PreferredTypen'est pas passé, laissez hintêtre "par défaut".
2. Sinon, si PreferredTypeest hintString, hintsoit "string".
3. Else PreferredTypeest hintNombre, nous allons hintêtre « nombre ».
4. Laissez exoticToPrimêtre GetMethod(input, @@toPrimitive).
5. ReturnIfAbrupt(exoticToPrim).
6. Si exoticToPrimn'est pas indéfini, alors
   a) Soit le résultat Call(exoticToPrim, input, «hint»).
   b) ReturnIfAbrupt(result).
   c) Si Type(result)n'est pas Object, renvoie le résultat.
   d) Lancez une exception TypeError.
7. Si hintest "par défaut", hintsoit "nombre".
8. Retour OrdinaryToPrimitive(input,hint).

Les valeurs autorisées pour l'indice sont "par défaut", "nombre" et "chaîne". Les objets Date sont uniques parmi les objets ECMAScript intégrés en ce sens qu'ils traitent "default" comme étant équivalent à "string". Tous les autres objets ECMAScript intégrés considèrent «default» comme étant équivalent à «number» . ( ECMAScript 20.3.4.45 )

Donc je pense qu'il se nullconvertit à 0.

J'ai eu le même problème !!. Actuellement, ma seule solution est de me séparer.

var a = null;
var b = undefined;

if (a===0||a>0){ } //return false  !work!
if (b===0||b>0){ } //return false  !work!

//but 
if (a>=0){ } //return true !

console.log( null > 0 );  // (1) false
console.log( null == 0 ); // (2) false
console.log( null >= 0 ); // (3) true

Mathématiquement, c'est étrange. Le dernier résultat indique que "null est supérieur ou égal à zéro", donc dans l'une des comparaisons ci-dessus, il doit être vrai, mais ils sont tous les deux faux.

La raison en est qu'un contrôle d'égalité ==et des comparaisons > < >= <=fonctionnent différemment. Les comparaisons convertissent null en nombre, le traitant comme 0. C'est pourquoi (3) null >= 0est trueet (1) null > 0est false.

D'autre part, le contrôle de l' égalité ==pour undefinedet nullest définie de telle sorte que, sans aucune conversion, ils sont égaux entre eux et ne sont pas égaux quoi que ce soit d' autre. C'est pourquoi (2) null == 0est false.