«

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

On Aug 4, 9:08 am, Metre Meter <metreme...@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

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.

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/not...ity-operators/

Thus, cases

null == false
undefined == false

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

Dmitry.

On Aug 4, 2:27*pm, "Dmitry A. Soshnikov" <dmitry.soshni...@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/not...ity-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

On Aug 4, 2:46*am, RobG <rg...@iinet.net.au> wrote:
> On Aug 4, 9:08 am, Metre Meter <metreme...@yahoo.co.uk> wrote:
> In the first case, you are using the (abstract) equals operator (==).
>
> 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.

What you say above is (broadly) how I guessed it worked... I just
thought that was a rather strange way to do it. I suspect that most
people would expect (and consider it logical) that and "if (whatever)
blah;" and "if (whatever == true) blah;" would always have the same
result.

> 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?

True, but I'd say that the complexity arises from the counter-
intuitive way that JS treats boolean equality and standalone
implicitly-converted boolean values differently. But that's just my
opinion.

- MM

On Aug 4, 2:01*pm, Richard Cornford <Rich...@litotes.demon.co.uk>
wrote:
> On Aug 4, 12:08 am, Metre Meter wrote:
> > So can I assume that null is considered false in a boolean
> > context,
>
> Insofar as there is a "boolean context"

I was probably thinking of JS in a Perl-esque manner that might not
have been applicable (or appropriate) there...

> 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.

Yes, it's all very... interesting. Actually, it *is* interesting in an
abstract way, but not the sort of "intersting" you want when
programming

> The results of your observations correspond with the correct
> behaviour.
>
> The depth comes from understanding the applicable algorithms from ECMA
> 262.

I was thinking as much of the depth of the reasoning and logic behind
the decision to have direct boolean evaluation of an expression *not*
always match that expression's equality with "true". Unfortunately, it
appears that there isn't any...

> 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).

*Now* you put your finger on it. I assumed that there may have been
some sound logical reason for doing things this way that I wasn't
aware of... and it doesn't appear that there is(!) Thanks anyway.

- MM

On Aug 5, 7:45*am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
> If it is reasonable (or intuitive) to expect that all values that have
> 'falseness' are equal is it any less reasonable to expect that all
> values that have 'trueness' are equal?

I'm not entirely sure what you're suggesting (*) or what you think *I*
was suggesting(!)

I meant that for any arbitrary value of an arbitrary type "x", the
same boolean result should be returned whether it's implicitly
converted to a boolean (e.g. in an if (X) statement) or whether it's
compared explicitly to a boolean true for equality (e.g. if (X ==
true)).

That is,

if (X == true)

should be functionally identical to

if (!!X == true)

In all honesty, I think that this is what most people would expect
unless they thought about it.

- MM

(*) By "falseness" and "trueness", do you mean the result as evaluated
in (e.g.) if (X) {...}?