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]

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

[Randy Webb]

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

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Arnaud Diederen]

Randy Webb <Hi************@aol.comwrites:

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

Best,
Arnaud

[Doug Miller]

In article <1c**********************************@q39g2000hsf. googlegroups.com>, Java script Dude <de********@yahoo.cawrote:

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

--
Regards,
Doug Miller (alphageek at milmac dot com)

It's time to throw all their damned tea in the harbor again.

[David Mark]

On Jan 16, 4:19*am,
[e-mail].c om (Arnaud Diederen
(aundro)) wrote:

Randy Webb <[e-mail]:

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

[timothytoe]

On Jan 16, 6:13 am, David Mark <[e-mail]:

On Jan 16, 4:19 am,
[e-mail].c om (Arnaud Diederen

(aundro)) wrote:

Randy Webb <[e-mail]:

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

[Arnaud Diederen]

timothytoe <ti********@gmail.comwrites:

On Jan 16, 6:13 am, David Mark <[e-mail]:

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

I agree with timothytoe; being string (in your own code) does not seem
like a bad practice to me.

Best,
A.

[Arnaud Diederen]

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.

[David Mark]

On Jan 16, 10:46*am, timothytoe <[e-mail]:

On Jan 16, 6:13 am, David Mark <[e-mail]:

On Jan 16, 4:19 am,
[e-mail].c om (Arnaud Diederen

(aundro)) wrote:

Randy Webb <[e-mail]:
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 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.

[David Mark]

On Jan 16, 11:04*am,
[e-mail].c om (Arnaud Diederen
(aundro)) wrote:

timothytoe <[e-mail]:

On Jan 16, 6:13 am, David Mark <[e-mail]:

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.

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]

David Mark <dm***********@gmail.comwrites:

On Jan 16, 11:04Â*am,
[e-mail].c om (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.

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]

On Jan 16, 8:46 am,
[e-mail].c om (Arnaud Diederen
(aundro)) wrote:

David Mark <[e-mail]:

On Jan 16, 11:04 am,
[e-mail].c om (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.

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.

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]

On Jan 16, 4:19 am,
[e-mail].c om (Arnaud Diederen
(aundro)) wrote:

Randy Webb <[e-mail]:

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

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]

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

[Thomas 'PointedEars' Lahn]

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

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

[Tim Streater]

In article <47**************@PointedEars.de>,
Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

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

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.

[Thomas 'PointedEars' Lahn]

Tim Streater wrote:

Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

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

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, <f8*******************@news.demon.co.uk>

[Arnaud Diederen]

Tim Streater <ti**********@dante.org.ukwrites:

In article <47**************@PointedEars.de>,
Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

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

>
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

[Tim Streater]

In article <47**************@PointedEars.de>,
Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

Tim Streater wrote:

Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

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.

[Tim Streater]

In article <87************@paddy.ionicsoft.com>,
[e-mail] (Arnaud Diederen
(aundro)) wrote:

Tim Streater <ti**********@dante.org.ukwrites:

In article <47**************@PointedEars.de>,
Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

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.

[David Mark]

On Jan 17, 7:13*am, Tim Streater <[e-mail]:

In article <[e-mail]>,
*Thomas 'PointedEars' Lahn <[e-mail]:

Tim Streater wrote:

Thomas 'PointedEars' Lahn <[e-mail]:
>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

[David Mark]

On Jan 17, 7:14*am, Tim Streater <[e-mail]:

In article <[e-mail]>,
*[e-mail]. com (Arnaud Diederen

*(aundro)) wrote:

Tim Streater <[e-mail]:

In article <[e-mail]>,
*Thomas 'PointedEars' Lahn <[e-mail]:

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

[Thomas 'PointedEars' Lahn]

Tim Streater wrote:

In article <47**************@PointedEars.de>,
Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

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

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

[Arnaud Diederen]

David Mark <dm***********@gmail.comwrites:

On Jan 17, 7:14Â*am, Tim Streater <[e-mail]:

>In article <[e-mail]>,
Â*[e-mail] t.com (Arnaud Diederen

Â*(aundro)) wrote:

Tim Streater <[e-mail]:

In article <[e-mail]>,
Â*Thomas 'PointedEars' Lahn <[e-mail]:

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

A.

[Tim Streater]

In article <87************@paddy.ionicsoft.com>,
[e-mail] (Arnaud Diederen
(aundro)) wrote:

David Mark <dm***********@gmail.comwrites:

On Jan 17, 7:14Â*am, Tim Streater <[e-mail]:

In article <[e-mail]>,
Â*[e-mail] .com (Arnaud Diederen

Â*(aundro)) wrote:
Tim Streater <[e-mail]:

In article <[e-mail]>,
Â*Thomas 'PointedEars' Lahn <[e-mail]:

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

[Tim Streater]

In article <47**************@PointedEars.de>,
Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

Tim Streater wrote:

In article <47**************@PointedEars.de>,
Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

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.

Anyone making such a statement has no clue what they are talking about.

Besides, all generalizations are false ;-)

You mean - the string I typed in evaluates to "false" ??

Damn.

[Douglas Crockford]

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/

[David Mark]

On Jan 21, 5:32*pm, Douglas Crockford <[e-mail]:

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.

For the first example, the == operator will always give the right
result. For the second it will not. I don't see any benefit in using
the === operator for everything. To me it makes the code's intentions
less clear.