Subtle difference between boolean value and boolean comparison?
in [JavaScript]
|
Prev: FAQ Topic - What is a host object? (2010-08-04)
Next: AJAX routine needs to be triggered automatically instead of via onChange event
From: Metre Meter on 4 Aug 2010 18:31 On Aug 4, 2:46 am, RobG <rg...(a)iinet.net.au> wrote: > On Aug 4, 9:08 am, Metre Meter <metreme...(a)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
From: Metre Meter on 4 Aug 2010 18:42 On Aug 4, 2:01 pm, Richard Cornford <Rich...(a)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
From: Richard Cornford on 5 Aug 2010 02:45 Metre Meter wrote: >On Aug 4, 2:46 am, RobG wrote: <snip> >> 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 mplicitly-converted boolean values > differently. But that's just my opinion. :-) 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? If any value either has trueness or has falseness then if both expectations are satisfied the notion of equality (and inequality) becomes much less useful. If both expectations cannot be usefully satisfied then what makes it more "intuitive" for a particular one of them to be satisfied rather than neither of them being satisfied? Javascript elects to satisfy neither, and whether that is counter intuitive or not probably depends on where the expectation that only all values that have falseness should be equal comes from. Richard.
From: Metre Meter on 6 Aug 2010 16:40
On Aug 5, 7:45 am, "Richard Cornford" <Rich...(a)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) {...}? |