Dort scheint eine Diskrepanz zwischen dem gemeinsamen Verständnis von == und dem zu sein, was es tatsächlich tut. Um einen Hintergrund für das Problem zu geben:
Scheinbar sind sowohl Number als auch String von object type. Keine Überraschung dort. Allerdings werden Dinge interessant für == , die true zurückgeben sollten, wenn die Operanden gleich unabhängig von ihrem Typ sind.
Nach eine etwas authorative Beschreibung :
Operatoren versuchen es das Objekt in einen primitiven Wert, einen String- oder Zahlenwert konvertieren, Verwenden der Methoden valueOf und toString der Objekte. Wenn dieser Versuch Um das Objekt zu konvertieren, wird ein Laufzeitfehler generiert.
Kurz gesagt, == sollte Objekte nach ihrem primitiven Wert vergleichen. Überraschenderweise:
Wenn beide Operanden Objekte sind, verwendet der Operator == weder toString() noch valueOf() , sondern etwas anderes.
Was ist die Standarddefinition der Objektgleichheit für == ?
Kurz gesagt, wenn Operanden Objekte sind, vergleicht == Referenzen.
Von der offiziellen Spezifikation , Seite 80:
11.9.3 Der abstrakte Gleichheitsvergleichsalgorithmus
Wenn Typ (x) derselbe wie Typ (y) ist, dann
a - e wurde weggelassen, weil es nicht für Objekte gilt
f. Geben Sie true zurück, wenn sich x und y auf dasselbe Objekt beziehen. Andernfalls gebe false zurück.
Ich glaube, was Sie dort sehen, und was aus der "etwas autoritativen Beschreibung" herausbleibt, ist, dass == versucht, ein Objekt in ein Primitiv umzuwandeln, wenn und nur wenn sein Comparand ein Primitiv ist. Wenn beide Operanden Objekte sind, werden sie als Objekte verglichen, und der Gleichheitstest ist nur dann wahr, wenn sie das gleiche Objekt sind (dh dieselbe Instanz - unterschiedliche Objekte mit denselben Attributen sind unterschiedlich, wie Sie in Ihrem Fall numa == numb sehen ).
Tags und Links javascript type-conversion types operators