Equality expressions are a special case of relational expressions. They deal strictly with equality or non-equality.
There are two equality operators that you can use to make an equality expression:
The == operator tests for equality.
The != operator tests for inequality.
As a general rule, equality expressions will yield a true or false result in a more forgiving way than relational expressions. Passing NaN, undefined and null values to relational expressions may yield undefined values as results, where an equality expression would still return a Boolean value.
The comparisons between objects are likely to be a shallow comparison. If you are comparing two objects of the same type, the comparison logic will check to see if you are referring to the same instance. That is a test for identity and not equality. A deeper comparison might compare two similar objects on a property by property basis. They wouldn't be identical, but they may be equivalent. You could simulate this with a script function that returns true or false having done a deep comparison.
Tests for equality require further deductive reasoning on the part of the interpreter. The values are converted to their preferred types. If the types are the same, then the values can be compared easily either as Numbers or Strings. If the types are different, the further conversion is necessary before the comparison can be completed. In that case, Boolean become Numbers as do any other non-numeric values and numeric comparison predominates.
Comparing null with undefined values does not require any conversion and they will compare equal.
Comparing values with null can expose some bugs in earlier implementations. It may be safer to rely on Boolean conversions and simply test for true or false.
The ECMA standard (edition 3) sets out the rules for testing two values for equality (somewhat simplified):
If they are of different types, they are unequal - return false.
If the type of the first argument is undefined or null return true.
For numeric values NaN in either case return false.
Positive and negative zeros are represented differently internally but are equal.
Otherwise equal numbers return true and unequal numbers return false.
For strings, the two values must contain the same sequence of characters for them to be equal.
Boolean values must be equal and they have no special states to consider.
Object references must refer to the same object instance.
The values null and undefined are considered to be equal.
If necessary, ToNumber() and ToPrimitive() functions are called to coerce objects when one value is a primitive and the other is an object.
If all of the above fail to match equal then a false value is returned.
It seems odd to assume equality to be true if the type of the arguments is not absolutely clear but this may be necessary to allow implementations some flexibility in the internal representation of values which may not have a defined type.
It might also be strange to see that if either value is NaN then a false value is returned. This is necessary because NaN is indeterminate. It is not a specific value and can be caused by a variety of circumstances when an expression yields an out of bounds value. There is no guarantee that two individual NaN values resulted from the same circumstance and hence they are assumed to be unequal.
Referring to the same object also includes joined objects which are an internal mechanism for sharing functionality between objects. This is not exposed to the script interface.
Earlier versions of MSIE and Netscape exhibited bugs in the comparison logic between the results of comparisons involving NaN, null and 0, where type conversions led to inconsistent behavior.
Since historically there are known bugs in comparisons involving null values, you should avoid using them. The following:
if(a) { someCode }
may be more reliable in some implementations than:
if(a != null) { someCode }
// Force a string comparison myResult = (a+'' == b+''); // Force a numeric comparison myResult = (a-0 == b-0); // Force a boolean comparison myResult = (!a == !b);
ECMA 262 edition 2 - section - 11.9
ECMA 262 edition 3 - section - 11.9
Wrox Instant JavaScript - page - 39
Prev | Home | Next |
Equal to (==) | Up | Equality operator |
JavaScript Programmer's Reference, Cliff Wootton Wrox Press (www.wrox.com) Join the Wrox JavaScript forum at p2p.wrox.com Please report problems to support@wrox.com © 2001 Wrox Press. All Rights Reserved. Terms and conditions. |