Subtle difference between boolean value and boolean comparison?

Discussion in 'Javascript' started by Metre Meter, Aug 4, 2010.

  1. Metre Meter

    Metre Meter Guest

    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
     
    Metre Meter, Aug 4, 2010
    #1
    1. Advertising

  2. Metre Meter

    RobG Guest

    On Aug 4, 9: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.


    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
     
    RobG, Aug 4, 2010
    #2
    1. Advertising

  3. 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.
     
    Richard Cornford, Aug 4, 2010
    #3
  4. 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.
     
    Dmitry A. Soshnikov, Aug 4, 2010
    #4
  5. Metre Meter

    Metre Meter Guest

    On Aug 4, 2:27 pm, "Dmitry A. Soshnikov" <>
    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
     
    Metre Meter, Aug 4, 2010
    #5
  6. Metre Meter

    Metre Meter Guest

    On Aug 4, 2:46 am, RobG <> wrote:
    > On Aug 4, 9:08 am, Metre Meter <> 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
     
    Metre Meter, Aug 4, 2010
    #6
  7. Metre Meter

    Metre Meter Guest

    On Aug 4, 2:01 pm, Richard Cornford <>
    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
     
    Metre Meter, Aug 4, 2010
    #7
  8. Metre Meter

    Metre Meter Guest

    On Aug 5, 7:45 am, "Richard Cornford" <>
    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) {...}?
     
    Metre Meter, Aug 6, 2010
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jakk
    Replies:
    4
    Views:
    12,246
  2. stixwix
    Replies:
    2
    Views:
    1,178
    Thomas Fritsch
    Nov 30, 2005
  3. J Leonard
    Replies:
    4
    Views:
    12,694
    Mark Space
    Jan 19, 2008
  4. Palindrom
    Replies:
    7
    Views:
    267
    Jonathan Gardner
    Aug 13, 2008
  5. Dmitriy V'jukov
    Replies:
    25
    Views:
    2,184
    Anthony Williams
    Sep 9, 2008
Loading...

Share This Page