0 == false == ""

[Java script Dude]

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

 

[Thomas 'PointedEars' Lahn]

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

 

[Arnaud Diederen]

Thomas 'PointedEars' Lahn said the following on 1/15/2008 11:13 PM:

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

 

[Doug Miller]

Now I can understand that 0 equal false, but should "" also equal
false?
Yes.

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.

That's a NAPWAD: Not A Problem - Works As Designed.

 

[David Mark]

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.

 

[timothytoe]

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.

 

[Arnaud Diederen]

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.

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.

 

[Arnaud Diederen]

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.

 

[David Mark]

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.

 

[David Mark]

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.

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.

 

[Arnaud Diederen]

On Jan 16, 11:04 am,
(e-mail address removed) (Arnaud
Diederen

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.

 

[timothytoe]

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.

JavaScript is one of many languages whose syntax comes largely from C.
In this whole family of languages, = is assignment and == tests
equivalence. Someone coming from one of the other C-syntax languages
may not know about ===, or may simply ignore it when they first read
about it.

It's the beginner in most danger. A beginner is learning everything at
once, and I think they'd be safer using === throughout than ==
throughout.

Using just ==, the beginner will probably get hung up several times on
"hey, 0 isn't null!" Using just ===, the beginner would probably be
fine.

I use both == and ===. I'm _always_ thinking about what values could
possibly be compared when I make the choice, and what kind of things
could happen to show bad input to the code. For me, it's better to
think about it while you're coding than try to fix a bunch of weird
cases later.

So, yeah, programmers really should know == and ===. But I still think
beginners and programmers with a fast, sloppy style are better off
with a habit of using === than a habit of using ==.

If you're working with other programmers, you may not have a choice. I
know of places that have strict style requirements (yes, even down to
tabs and spaces). Some place require that you pass jslint (with
certain settings) or another code checker. jslint has been a great
debugging tool for me. I'd use its spacing requirements, except I
demand two-space tabs and I think it wants four.

Loners can do what they like, but don't be surprised if you someday
have to defend your == or === to a coworker.

 

[timothytoe]

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");
}

 

[tim.c.quinn]

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

 

[tim.c.quinn]

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

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 1/15/2008 11:13 PM:

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

 

[Tim Streater]

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.

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.

There was a thread about this rubbish in PHP recently.

 

[Arnaud Diederen]

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

 

[Thomas 'PointedEars' Lahn]

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

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

 

[Tim Streater]

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

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.

Anyone doing a type conversion of string to boolean needs a good smack.