From: Metre Meter on
Hi there,

I came across an aspect of Javascript I hadn't considered before.

Null compares equal (==) to another null, or to undefined and not to
anything else. Logically, therefore it shouldn't compare equal to a
boolean false value- and as expected this code:-

if (null == false) {
alert('Yes');
} else {
alert('No');
}

displays "No".

Yet, if the condition above is changed to simply "if (null) {...} else
{...}", the result shown is "No", implying that null on its own *is*
considered "false". Yet it isn't considered "equal" to the boolean
false.

So can I assume that null is considered false in a boolean context,
yet doesn't match (i.e. return a true value for) a comparison with a
boolean value? While logical, this seems strange.

Can someone confirm (or otherwise) this and/or explain the situation
in more depth? Thank you! :-)

- MM
From: RobG on
On Aug 4, 9:08 am, Metre Meter <metreme...(a)yahoo.co.uk> wrote:
> Hi there,
>
> I came across an aspect of Javascript I hadn't considered before.
>
> Null compares equal (==) to another null, or to undefined and not to
> anything else.

Per ECMA-262 ed 3, see § 11.9.3


> Logically, therefore it shouldn't compare equal to a
> boolean false value- and as expected this code:-
>
> if (null == false) {
> alert('Yes');
> } else {
> alert('No');
> }
>
> displays "No".
>
> Yet, if the condition above is changed to simply "if (null) {...} else
> {...}", the result shown is "No", implying that null on its own *is*
> considered "false". Yet it isn't considered "equal" to the boolean
> false.

In the first case, you are using the (abstract) equals operator (==).
It compares two expressions to each other as defined in the abstract
equality comparison algorithm (see reference above).

In the second case, the expression in brackets is evaluated and type-
converted to boolean using the rules in § 12.5. The outcome depends on
whether it resolves to boolean true or false, there is no comparison
with some other expression.

Consider:

alert( null == 0 ); // false
alert( !null == !0 ); // true

where the use of the logical NOT operator (!) forces conversion to
boolean before the comparison is made.


> So can I assume that null is considered false in a boolean context,
> yet doesn't match (i.e. return a true value for) a comparison with a
> boolean value?

Better to say that null type-converts to boolean false and that
comparisons between null and boolean values always return false. It is
important to know the types of values that an equality expression
might be called upon to evaluate. It is often more suitable to use:

if ( <expression> )


than

if ( <expression> == true )


which can be made equivalent to the first using:

if ( !!<expression> == true )


but why do that when the first is simpler and shorter?


--
Rob
From: Richard Cornford on
On Aug 4, 12:08 am, Metre Meter wrote:
> Hi there,
>
> I came across an aspect of Javascript I hadn't considered
> before.
>
> Null compares equal (==) to another null, or to undefined
> and not to anything else. Logically, therefore it shouldn't
> compare equal to a boolean false value- and as expected
> this code:-
>
> if (null == false) {
> alert('Yes');
> } else {
> alert('No');
> }
>
> displays "No".
>
> Yet, if the condition above is changed to simply "if (null)
> {...} else {...}", the result shown is "No", implying that
> null on its own *is* considered "false". Yet it isn't
> considered "equal" to the boolean false.
>
> So can I assume that null is considered false in a boolean
> context,

Insofar as there is a "boolean context" that would be context where
the internal ToBoolean function is applied to the result of evaluating
an expression. The ToBoolean function returns false for null,
undefined, zero, NaN, the empty string and boolean false.

> yet doesn't match (i.e. return a true value for) a comparison
> with a boolean value? While logical, this seems strange.

Taken in isolation, maybe, but undefined behaves the same as null, and
NaN type-converts to false, but is not equal to any value, including
itself.

> Can someone confirm (or otherwise) this

The results of your observations correspond with the correct
behaviour.

> and/or explain the situation
> in more depth? Thank you! :-)

The depth comes from understanding the applicable algorithms from ECMA
262. Why the algorithms are as they are is no something that cannot be
given a definitive answer by anyone but the authors of the
specification (and possibly not even them).

Richard.
From: Dmitry A. Soshnikov on
On 04.08.2010 3:08, Metre Meter wrote:
> Hi there,
>
> I came across an aspect of Javascript I hadn't considered before.
>
> Null compares equal (==) to another null, or to undefined and not to
> anything else. Logically, therefore it shouldn't compare equal to a
> boolean false value- and as expected this code:-
>
> if (null == false) {
> alert('Yes');
> } else {
> alert('No');
> }
>
> displays "No".
>
> Yet, if the condition above is changed to simply "if (null) {...} else
> {...}", the result shown is "No", implying that null on its own *is*
> considered "false". Yet it isn't considered "equal" to the boolean
> false.
>
> So can I assume that null is considered false in a boolean context,
> yet doesn't match (i.e. return a true value for) a comparison with a
> boolean value? While logical, this seems strange.
>
> Can someone confirm (or otherwise) this and/or explain the situation
> in more depth? Thank you! :-)
>

The main conversion used in non-strict equality operator comparison is
/ToNumber/ but not /ToBoolean/.

Please read this small, but informative note (there all these cases are
discussed):

http://dmitrysoshnikov.com/notes/note-2-ecmascript-equality-operators/

Thus, cases

null == false
undefined == false

are special. Here only `false' is converted ToNumber and not undefined/null.

Dmitry.
From: Metre Meter on
On Aug 4, 2:27 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> The main conversion used in non-strict equality operator comparison is
> /ToNumber/ but not /ToBoolean/.
>
> Please read this small, but informative note (there all these cases are
> discussed):
>
> http://dmitrysoshnikov.com/notes/note-2-ecmascript-equality-operators/

That looks interesting, thanks- though not *that* short... especially
given that even the first bit opens a can of worms. :-)

Definitely taking a closer look at it when I have more time though,
cheers.

- MM