Dlaczego `null> = 0 && null <= 0`, ale nie` null == 0`?

Question

Musiałem napisać procedurę, która zwiększa wartość zmiennej o 1, jeśli jej typ to number i przypisuje 0 do zmiennej, jeśli nie, gdzie początkowo jest zmienna null lub undefined.

Pierwsza implementacja to v >= 0 ? v += 1 : v = 0, ponieważ uważałem, że cokolwiek, a nie liczba, sprawiłoby, że wyrażenie arytmetyczne było fałszywe, ale było błędne, ponieważ null >= 0 zostało ocenione jako prawdziwe. Potem dowiedziałem się, że null zachowuje się jak 0, a wszystkie poniższe wyrażenia są prawdziwe.

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

Oczywiście null nie jest 0. null == 0 oceniana jest na false. To sprawia, że ​​pozornie tautologiczna ekspresja jest fałszywa.

Dlaczego jest null jak 0, chociaż w rzeczywistości nie jest 0?

Answer 1

Twoje prawdziwe pytanie wydaje się być:

Dlaczego:

null >= 0; // true 

Ale:

null == 0; // false 

Co naprawdę się dzieje, że Większy niż lub równy Operator (>=), wykonuje przymus typu (ToPrimitive), z podpowiedzią typ Number, faktycznie wszystkie operatory relacyjne mają takie zachowanie.

null jest traktowany w specjalny sposób przez operatora , który jest równy Operatorowi (==). W skrócie, to tylko wymusza do undefined:

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

Wartość takich jak false, '', '0' i [] podlegają numerycznej typu przymus, wszystkie z nich przymusić do zera.

Możesz zobaczyć wewnętrzne szczegóły tego procesu w The Abstract Equality Comparison Algorithm i The Abstract Relational Comparison Algorithm.

W skrócie:

• Porównanie relacyjny: jeśli obie wartości nie są typu String, ToNumber nazywa się na obu. Jest to to samo, co dodanie z przodu +, które dla zerowych wiązań do 0.

• Porównanie równości: tylko połączenia ToNumber na łańcuchach, liczbach i bajtach.

Answer 2

Chciałbym rozszerzyć pytanie do dalszej poprawy widoczności problemu:

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

To po prostu nie ma sensu. Podobnie jak języki ludzkie, te rzeczy trzeba się nauczyć na pamięć.

Answer 3

Miałem ten sam problem !!. Obecnie moim jedynym rozwiązaniem jest rozdzielenie.

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 ! 

Answer 4

JavaScript ma zarówno surowe i typu konwertazy porównań

null >= 0; prawda ale (null==0)||(null>0) jest fałszywa

null <= 0; jest prawdą, ale (null==0)||(null<0) jest fałszywa

"" >= 0 jest również prawdą

W przypadku relacyjnych porównań abstrakcyjnych (< =,> =) operandy są najpierw konwertowane na prymitywy, a następnie na ten sam typ, przed porównaniem.

typeof null returns "object"

Gdy typ jest obiektem JavaScript próbuje stringify obiektu (tj null) następujące kroki są podejmowane (ECMAScript 2015):

1. Jeśli PreferredType nie została uchwalona, ​​niech hint być „default ".
2. Inna, jeśli PreferredType jest hint String, niech hint będzie "ciągiem".
3. Else PreferredType to hint Liczba, niech hint będzie "liczbą".
4. Niech exoticToPrim będzie GetMethod(input, @@toPrimitive).
5. ReturnIfAbrupt(exoticToPrim).
6. Jeśli exoticToPrim nie jest niezdefiniowany, to
   a) Niech wynikiem będzie Call(exoticToPrim, input, «hint»).
   b) ReturnIfAbrupt(result).
   c) Jeśli Type(result) nie jest obiektem, wynik zwracany.
   d) Zgłasza wyjątek TypeError.
7. Jeśli "hint" jest "domyślne", niech hint będzie "liczbą".
8. Powrót OrdinaryToPrimitive(input,hint).

Dozwolone wartości wskazówki to "default", "number" i "string". Obiekty Date są unikalne wśród wbudowanych obiektów ECMAScript, ponieważ traktują "default" jako równoważne "string". Wszystkie inne wbudowane obiekty ECMAScript traktują "domyślny" jako równoważny "numerowi". (ECMAScript 20.3.4.45)

Więc myślę null konwertuje do 0.