434,847 Members | 2,296 Online
Need help? Post your question and get tips & solutions from a community of 434,847 IT Pros & Developers. It's quick & easy.

# 0 == false == ""

 P: n/a Greetings, Now I can understand that 0 equal false, but should "" also equal false? Apparently the answer is yes. When I test both Firefox and IE, they both say ""==false . I assume this goes back to the original spec for JavaScript. Not very intuitive but I guess I can code around this. - JsD Jan 16 '08 #1
29 Replies

 P: n/a Java script Dude wrote: Now I can understand that 0 equal false, but should "" also equal false? Yes, it should. Apparently the answer is yes. When I test both Firefox and IE, they both say ""==false . Works as designed. I assume this goes back to the original spec for JavaScript. Maybe so, but it is more important that JavaScript 1.1+ and JScript 1.0+ implement the ECMAScript Language Specification which says in the Final revision of its 3rd Edition: | 11.9.1 The Equals Operator ( == ) | | The production EqualityExpression : EqualityExpression == | RelationalExpression is evaluated as follows: | | 1. Evaluate EqualityExpression. | 2. Call GetValue(Result(1)). | 3. Evaluate RelationalExpression. | 4. Call GetValue(Result(3)). | 5. Perform the comparison Result(4) == Result(2). (Section 11.9.3.) | 6. Return Result(5). | | [...] | | 11.9.3 The Abstract Equality Comparison Algorithm | | The comparison x == y, where x and y are values, produces true or | false. Such a comparison is performed as follows: | | 1. If Type(x) is different from Type(y), go to step 14. | 5.2 Algorithm Conventions | | [...] Type(x) is used as shorthand for “the type of x”. | [...] | 14. If x is null and y is undefined, return true. | 15. If x is undefined and y is null, return true. | 16. If Type(x) is Number and Type(y) is String, | return the result of the comparison x == ToNumber(y). | 17. If Type(x) is String and Type(y) is Number, | return the result of the comparison ToNumber(x) == y. | 18. If Type(x) is Boolean, return the result of the comparison | ToNumber(x) == y. | 19. If Type(y) is Boolean, return the result of the comparison | x == ToNumber(y). | 9.3 ToNumber | | The operator ToNumber converts its argument to a value of type Number | according to the following table: | | Input Type Result | -------------------------- | Undefined NaN | Null +0 | Boolean The result is 1 if the argument is true. | The result is +0 if the argument is false. | Number The result equals the input argument (no conversion). | String See grammar and note below. | Object Apply the following steps: | 1. Call ToPrimitive(input argument, hint Number). | 2. Call ToNumber(Result(1)). | 3. Return Result(2). Therefore ("" == +0): | 1. If Type(x) is different from Type(y), go to step 14. | [...] | 14. If x is null and y is undefined, return true. | 15. If x is undefined and y is null, return true. | 16. If Type(x) is Number and Type(y) is String, | return the result of the comparison x == ToNumber(y). | 17. If Type(x) is String and Type(y) is Number, | return the result of the comparison ToNumber(x) == y. | 9.3.1 ToNumber Applied to the String Type | | [...] | A StringNumericLiteral that is empty or contains only white space is | converted to +0. Therefore (+0 == +0): | 1. If Type(x) is different from Type(y), go to step 14. | 2. If Type(x) is Undefined, return true. | 3. If Type(x) is Null, return true. | 4. If Type(x) is not Number, go to step 11. | 5. If x is NaN, return false. | 6. If y is NaN, return false. | 7. If x is the same number value as y, return true. | 5.2 Algorithm Conventions | | When an algorithm is to produce a value as a result, the directive | “return x” is used to indicate that the result of the algorithm is | the value of x and that the algorithm should terminate. Not very intuitive Yes, it is. For example, it allows for if (stringValue) without having to compare against the length of the string or to check for a whitespace-only string value. but I guess I can code around this. Yes, you can. Use the Strict Equality Operator (`===') instead, which does not perform implicit type conversion; it is well-supported: http://PointedEars.de/es-matrix PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16 Jan 16 '08 #2

 P: n/a Thomas 'PointedEars' Lahn said the following on 1/15/2008 11:13 PM: Java script Dude wrote: >Now I can understand that 0 equal false, but should "" also equalfalse? Yes, it should. >Apparently the answer is yes. When I test both Firefox and IE, theyboth say ""==false . Works as designed. >I assume this goes back to the original spec for JavaScript. Maybe so, but it is more important that JavaScript 1.1+ and JScript 1.0+ implement the ECMAScript Language Specification which says in the Final revision of its 3rd Edition: No, what is more important than what some Specification says is what browsers actually do with code. -- Randy Chance Favors The Prepared Mind comp.lang.javascript FAQ - http://jibbering.com/faq/index.html Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ Jan 16 '08 #3

 P: n/a Randy Webb Java script Dude wrote: >>Now I can understand that 0 equal false, but should "" also equalfalse? Yes, it should. >>Apparently the answer is yes. When I test both Firefox and IE, theyboth say ""==false . Works as designed. >>I assume this goes back to the original spec for JavaScript. Maybe so, but it is more important that JavaScript 1.1+ and JScript 1.0+implement the ECMAScript Language Specification which says in the Finalrevision of its 3rd Edition: No, what is more important than what some Specification says is what browsers actually do with code. And, for what it's worth (just for the OP): aundro@paddy:~\$ js js# 0 == "" true js# 0 === "" false js# I personally tend to use the === operator as often as possible. Best, Arnaud Jan 16 '08 #4

 P: n/a In article <1c**********************************@q39g2000hsf. googlegroups.com>, Java script Dude Now I can understand that 0 equal false, but should "" also equalfalse? Yes. >Apparently the answer is yes. When I test both Firefox and IE, theyboth say ""==false . I assume this goes back to the original spec forJavaScript.Not very intuitive but I guess I can code around this. That's a NAPWAD: Not A Problem - Works As Designed. -- Regards, Doug Miller (alphageek at milmac dot com) It's time to throw all their damned tea in the harbor again. Jan 16 '08 #5

 P: n/a On Jan 16, 4:19*am, a...@remove.this.and.keep.what.follows.ionicsoft.c om (Arnaud Diederen (aundro)) wrote: Randy Webb Apparently the answer is yes. When I test both Firefox and IE, theyboth say ""==false . Works as designed. >I assume this goes back to the original spec for JavaScript. Maybe so, but it is more important that JavaScript 1.1+ and JScript 1.0+ implement the ECMAScript Language Specification which says in the Final revision of its 3rd Edition: No, what is more important than what some Specification says is what browsers actually do with code. And, for what it's worth (just for the OP): aundro@paddy:~\$ js js# 0 == "" true js# 0 === "" false js# I personally tend to use the === operator as often as possible. You should use it only when it is needed. Too often I see things like this: typeof o === 'object' This makes no sense as a typeof operation evaluates to a string (comparing two strings doesn't involve implicit type conversion.) However, for example, if a function's argument x can be a string or null, then strict comparison would be the way to test it: x === null If you used a loose comparison on an empty string, you would get the wrong result. Jan 16 '08 #6

 P: n/a On Jan 16, 6:13 am, David Mark Java script Dude wrote: >>Now I can understand that 0 equal false, but should "" also equal >>false? >Yes, it should. >>Apparently the answer is yes. When I test both Firefox and IE, they >>both say ""==false . >Works as designed. >>I assume this goes back to the original spec for JavaScript. >Maybe so, but it is more important that JavaScript 1.1+ and JScript 1.0+ >implement the ECMAScript Language Specification which says in the Final >revision of its 3rd Edition: No, what is more important than what some Specification says is what browsers actually do with code. And, for what it's worth (just for the OP): aundro@paddy:~\$ js js# 0 == "" true js# 0 === "" false js# I personally tend to use the === operator as often as possible. You should use it only when it is needed. Too often I see things like this: typeof o === 'object' This makes no sense as a typeof operation evaluates to a string (comparing two strings doesn't involve implicit type conversion.) However, for example, if a function's argument x can be a string or null, then strict comparison would be the way to test it: x === null If you used a loose comparison on an empty string, you would get the wrong result. I think it's best to use === by default and == when you specifically want to be loose. I think more bugs are caused by people using == when they should be using === than vice versa. When you say "makes no sense," well, it makes sense to me, because the programmer is simply saying "compare these things in a strict manner," and that's usually what's desired. You can even have jslint force disallow use of == and !=. That's pretty harsh, but it probably solves a lot of unexpected misuses of ==. At the least, it makes you consider whether you want strict comparison or not. It's safer to err on the side of strict than loose. Jan 16 '08 #7

 P: n/a timothytoe >You should use it only when it is needed.Too often I see things like this:typeof o === 'object' What's wrong with that? It just makes it easier for the javascript engine to do the comparison, as it doesn't even need to check the types of the two operands. >>This makes no sense as a typeof operation evaluates to a string(comparing two strings doesn't involve implicit type conversion.)However, for example, if a function's argument x can be a string ornull, then strict comparison would be the way to test it:x === nullIf you used a loose comparison on an empty string, you would get thewrong result. I think it's best to use === by default and == when you specifically want to be loose. I think more bugs are caused by people using == when they should be using === than vice versa. When you say "makes no sense," well, it makes sense to me, because the programmer is simply saying "compare these things in a strict manner," and that's usually what's desired. You can even have jslint force disallow use of == and !=. That's pretty harsh, but it probably solves a lot of unexpected misuses of ==. At the least, it makes you consider whether you want strict comparison or not. It's safer to err on the side of strict than loose. I agree with timothytoe; being string (in your own code) does not seem like a bad practice to me. Best, A. Jan 16 '08 #8

 P: n/a I wrote: I agree with timothytoe; being string (in your own code) does not seem like a bad practice to me. Typo. It is, of course, "being strict" A. Jan 16 '08 #9

 P: n/a On Jan 16, 10:46*am, timothytoe Now I can understand that 0 equal false, but should "" also equal >false? Yes, it should. >Apparently the answer is yes. When I test both Firefox and IE, they >both say ""==false . Works as designed. >I assume this goes back to the original spec for JavaScript. Maybe so, but it is more important that JavaScript 1.1+ and JScript1.0+ implement the ECMAScript Language Specification which says in the Final revision of its 3rd Edition: No, what is more important than what some Specification says is what browsers actually do with code. And, for what it's worth (just for the OP): aundro@paddy:~\$ js js# 0 == "" true js# 0 === "" false js# I personally tend to use the === operator as often as possible. You should use it only when it is needed. Too often I see things like this: typeof o === 'object' This makes no sense as a typeof operation evaluates to a string (comparing two strings doesn't involve implicit type conversion.) However, for example, if a function's argument x can be a string or null, then strict comparison would be the way to test it: x === null If you used a loose comparison on an empty string, you would get the wrong result. I think it's best to use === by default and == when you specifically want to be loose. I think more bugs are caused by people using == when they should be using === than vice versa. When you say "makes no sense," well, it makes sense to me, because the programmer is simply saying "compare these things in a strict manner," and that's usually what's desired. But the two sides are of equal types. Strict comparison is the same as loose in this case, so the extra equal sign is unnecessary. > You can even have jslint force disallow use of == and !=. That's pretty harsh, but it probably solves a lot of unexpected misuses of You can have JSLint do a lot of weird things, including counting indentation characters. ==. At the least, it makes you consider whether you want strict comparison or not. You should certainly always consider that. > It's safer to err on the side of strict than loose. I think an error on either side is just as bad. Jan 16 '08 #10

 P: n/a On Jan 16, 11:04*am, a...@remove.this.and.keep.what.follows.ionicsoft.c om (Arnaud Diederen (aundro)) wrote: timothytoe

 P: n/a David Mark >What's wrong with that? It just makes it easier for the javascriptengine to do the comparison, as it doesn't even need to check thetypes of the two operands. To implement a strict comparison, you have to check both types. How else would you know they are equal (which is required by a strict comparison.) On the other hand, a loose comparison between two strings does not require any type conversion. So I don't see any performance benefit either way. Looking at the ecma-262 (ecmascript 3rd edition) spec, comparing the description of the "strict comparison algorithm" (p 56) against that of the "abstract comparison algorithm" (p 55), there is a need to do a bit more checking for the latter algorithm in case the two operands are of different types (step 14; null == undefined || undefined == null). Of course, that is the description of the algorithm, and not an implementation. As a matter of fact, maybe implementations are even faster when using "==", rather than "===". Still, I think that using "===" bears some 'meaning' to the operation one wants to perform. Keeping aside that there might be no performance gain, why should we lose the semantic bit of using it? Regards, A. Jan 16 '08 #12

 P: n/a On Jan 16, 8:46 am, a...@remove.this.and.keep.what.follows.ionicsoft.c om (Arnaud Diederen (aundro)) wrote: David Mark

 P: n/a After my last message, I decided that instead of merely being strident and opinionated, I should try to say something that's of some practical use. So here goes. When you've written some new code and you're unsure as to what might go wrong in a comparison with null, "", 0, or NaN, do strict and loose comparisons and then alert, assert, or console.log any differences between the two. Leave the code in there long enough to catch all kinds of data you expect to go in there. Do unit testing if feasible. This is great for beginners to JavaScript. And it's sometimes useful for pros as well. test1 = (b==c); test2 = (b===c); if (test1!==test2) { console.log("something"); } Jan 16 '08 #14

 P: n/a On Jan 16, 4:19 am, a...@remove.this.and.keep.what.follows.ionicsoft.c om (Arnaud Diederen (aundro)) wrote: Randy Webb Apparently the answer is yes. When I test both Firefox and IE, theyboth say ""==false . Works as designed. >I assume this goes back to the original spec for JavaScript. Maybe so, but it is more important that JavaScript 1.1+ and JScript 1.0+ implement the ECMAScript Language Specification which says in the Final revision of its 3rd Edition: No, what is more important than what some Specification says is what browsers actually do with code. And, for what it's worth (just for the OP): aundro@paddy:~\$ js js# 0 == "" true js# 0 === "" false js# I personally tend to use the === operator as often as possible. Best, Arnaud Sweet! Was not aware of this operator in JavaScript. I will start using === more often as it is what I often mean in my logic. Thanks ;) - JsD Jan 17 '08 #15

 P: n/a but I guess I can code around this. Yes, you can. Use the Strict Equality Operator (`===') instead, which does not perform implicit type conversion; it is well-supported: Thanks Thomas for your suggestion above. Nice to see you still actively posting. - JsD Jan 17 '08 #16

 P: n/a Randy Webb wrote: Thomas 'PointedEars' Lahn said the following on 1/15/2008 11:13 PM: >Java script Dude wrote: >>Now I can understand that 0 equal false, but should "" also equalfalse? Yes, it should. >>Apparently the answer is yes. When I test both Firefox and IE, theyboth say ""==false . Works as designed. >>I assume this goes back to the original spec for JavaScript. Maybe so, but it is more important that JavaScript 1.1+ and JScript 1.0+implement the ECMAScript Language Specification which says in the Finalrevision of its 3rd Edition: No, what is more important than what some Specification says is what browsers actually do with code. As you well know, it is not just "some Specification" but *the* ECMAScript Specification which is widely implemented as specified, including Netscape/ Mozilla.org JavaScript 1.1+, Microsoft JScript 1.0+, Opera ECMAScript, KJS, Apple JavaScriptCore and so on. Stop posting FUD. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16 Jan 17 '08 #17

 P: n/a In article <47**************@PointedEars.de>, Thomas 'PointedEars' Lahn

 P: n/a Tim Streater wrote: Thomas 'PointedEars' Lahn Randy Webb wrote: >>Thomas 'PointedEars' Lahn said the following on 1/15/2008 11:13 PM:Java script Dude wrote:[...] When I test both Firefox and IE, they both say ""==false .Works as designed.I assume this goes back to the original spec for JavaScript.Maybe so, but it is more important that JavaScript 1.1+ and JScript 1.0+implement the ECMAScript Language Specification which says in the Finalrevision of its 3rd Edition:No, what is more important than what some Specification says is whatbrowsers actually do with code. As you well know, it is not just "some Specification" but *the* ECMAScriptSpecification which is widely implemented as specified, including Netscape/Mozilla.org JavaScript 1.1+, Microsoft JScript 1.0+, Opera ECMAScript, KJS,Apple JavaScriptCore and so on. Stop posting FUD. I am puzzled as to why anyone cares whether there are "underlying" values for true and false. True has value true and false has value false. That's all you need to know. You miss the point. This thread is about why the comparison "" == false evaluates to `true' (or IOW, why "" type-converts to `false' in a boolean expression), which is what the OP wanted to know. There was a thread about this rubbish in PHP recently. If you think of attempts at understanding as rubbish, then you should leave Usenet immediately. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, Jan 17 '08 #19

 P: n/a Tim Streater , Thomas 'PointedEars' Lahn As you well know, it is not just "some Specification" but *the* ECMAScriptSpecification which is widely implemented as specified, including Netscape/Mozilla.org JavaScript 1.1+, Microsoft JScript 1.0+, Opera ECMAScript, KJS,Apple JavaScriptCore and so on. Stop posting FUD. That's very PointedEars of you, Thomas (I know it doesn't actually mean anything, but those who have read your prose will probably understand it anyway). > I am puzzled as to why anyone cares whether there are "underlying" values for true and false. True has value true and false has value false. That's all you need to know. It's not so much a matter of "what's true and what's false" (*) as it a matter of " *how do you get* to those values", and that... > There was a thread about this rubbish in PHP recently. ...is not quite what I'd call "rubbish". A. (*) quite a few people already know that, as a matter of fact Jan 17 '08 #20

 P: n/a In article <47**************@PointedEars.de>, Thomas 'PointedEars' Lahn

 P: n/a In article <87************@paddy.ionicsoft.com>, ad@remove.this.and.keep.what.follows.ionicsoft.com (Arnaud Diederen (aundro)) wrote: Tim Streater , Thomas 'PointedEars' Lahn

 P: n/a On Jan 17, 7:13*am, Tim Streater , *Thomas 'PointedEars' Lahn Randy Webb wrote: >>Thomas 'PointedEars' Lahn said the following on 1/15/2008 11:13 PM: >>>Java script Dude wrote: >>>>[...] When I test both Firefox and IE, they both say ""==false Jan 17 '08 #23

 P: n/a On Jan 17, 7:14*am, Tim Streater , *a...@remove.this.and.keep.what.follows.ionicsoft. com (Arnaud Diederen *(aundro)) wrote: Tim Streater , *Thomas 'PointedEars' Lahn As you well know, it is not just "some Specification" but *the* ECMAScript >Specification which is widely implemented as specified, including Netscape/ >Mozilla.org JavaScript 1.1+, Microsoft JScript 1.0+, Opera ECMAScript, KJS, >Apple JavaScriptCore and so on. *Stop posting FUD. That's very PointedEars of you, Thomas (I know it doesn't actually mean anything, but those who have read your prose will probably understand it anyway). I am puzzled as to why anyone cares whether there are "underlying" values for true and false. True has value true and false has value false. That's all you need to know. It's not so much a matter of "what's true and what's false" (*) as it a matter of " *how do you get* to those values", and that... Try writing "true" or "false" as required. Required by whom? Jan 17 '08 #24

 P: n/a Tim Streater wrote: In article <47**************@PointedEars.de>, Thomas 'PointedEars' Lahn You miss the point. This thread is about why the comparison "" == falseevaluates to `true' (or IOW, why "" type-converts to `false' in a booleanexpression), which is what the OP wanted to know. Anyone doing a type conversion of string to boolean needs a good smack. Anyone making such a statement has no clue what they are talking about. Besides, all generalizations are false ;-) PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16 Jan 17 '08 #25

 P: n/a David Mark In article <87sl0wfzx6....@paddy.ionicsoft.com>,Â*a...@remove.this.and.keep.what.follows.ionicsof t.com (Arnaud Diederen Â*(aundro)) wrote: Tim Streater , Â*Thomas 'PointedEars' Lahn As you well know, it is not just "some Specification" but *the* ECMAScriptSpecification which is widely implemented as specified, including Netscape/Mozilla.org JavaScript 1.1+, Microsoft JScript 1.0+, Opera ECMAScript, KJS,Apple JavaScriptCore and so on. Â*Stop posting FUD. That's very PointedEars of you, Thomas (I know it doesn't actually mean anything, but those who have read your prose will probably understand it anyway). I am puzzled as to why anyone cares whether there are "underlying" values for true and false. True has value true and false has value false. That's all you need to know. It's not so much a matter of "what's true and what's false" (*) as it a matter of " *how do you get* to those values", and that... Try writing "true" or "false" as required. Required by whom? I don't get it either. A. Jan 17 '08 #26

 P: n/a In article <87************@paddy.ionicsoft.com>, ad@remove.this.and.keep.what.follows.ionicsoft.com (Arnaud Diederen (aundro)) wrote: David Mark , Â*a...@remove.this.and.keep.what.follows.ionicsoft .com (Arnaud Diederen Â*(aundro)) wrote: Tim Streater , Â*Thomas 'PointedEars' Lahn As you well know, it is not just "some Specification" but *the* >ECMAScript >Specification which is widely implemented as specified, including >Netscape/ >Mozilla.org JavaScript 1.1+, Microsoft JScript 1.0+, Opera >ECMAScript, KJS, >Apple JavaScriptCore and so on. Â*Stop posting FUD. That's very PointedEars of you, Thomas (I know it doesn't actually mean anything, but those who have read your prose will probably understand it anyway). I am puzzled as to why anyone cares whether there are "underlying" values for true and false. True has value true and false has value false. That's all you need to know. It's not so much a matter of "what's true and what's false" (*) as it a matter of " *how do you get* to those values", and that... Try writing "true" or "false" as required. Required by whom? I don't get it either. By whoever wants to get to the value, is what I meant. Jan 17 '08 #27

 P: n/a In article <47**************@PointedEars.de>, Thomas 'PointedEars' Lahn , Thomas 'PointedEars' Lahn

 P: n/a David Mark wrote: >I personally tend to use the === operator as often as possible. You should use it only when it is needed. Too often I see things like this: typeof o === 'object' This makes no sense as a typeof operation evaluates to a string (comparing two strings doesn't involve implicit type conversion.) However, for example, if a function's argument x can be a string or null, then strict comparison would be the way to test it: x === null If you used a loose comparison on an empty string, you would get the wrong result. I think you should use the operator that always gives the right result, and never use the operator that sometimes gives the wrong result. http://javascript.crockford.com/ Jan 21 '08 #29

 P: n/a On Jan 21, 5:32*pm, Douglas Crockford

### This discussion thread is closed

Replies have been disabled for this discussion.