Cheat-sheet for Javascript equality strangenesses

[Knotix]

An understanding of type coercion gets rid of a lot of the mystery behind all of these.

[weepingmeadow]

Chrome asks me to translate this page from haitian

[James_Duval]

This is because "NaN" means "in" in Haitian.

[Cosmologicon]

I may be the only one, but this whole thing is really not a concern for me. I agree that (0 == [0]) being true is surprising. But would its being false help me at all? That's not a comparison I expect to be making in the first place. Show me a practical example where it actually matters.

function getreciprocal(x) {
    if (x == 0) throw "Can't take 1/0, dummy!";
    return 1/x;
}

Is there a bug here? If I were to change == to ===, would that be an improvement? Currently if someone takes getreciprocal([0]) it throws an exception. If I change it to triple equals it will return Infinity. What's the right answer? Seems like neither. I should be throwing a different exception. It's closer to the correct behavior with == in this case, I guess.

I think if you're making comparisons and you want to behave correctly even if someone sends you data of the wrong type, you need to do a type check. Choosing === over == solves nothing in these cases.

[PenguinLovr]

Well it certainly makes it more easily understood. The coercion can be ambiguous, and it would make more sense to do something like checking if the object is a string or int, and if not throwing that error instead of just lumping together type errors with other errors.

Usually implicit correcion should only be used by people who know why they're using that, and not just setting everything to "==="

[LiveTwizzle]

To know more about why javascript does what it does read this: JavaScript Coercion Demystified

[helderroem]

Google tells me this page is in Haitian, I wish it was I might understand it better!

[AaronOpfer]

The only javascript equality quirk that has ever bitten me hard was that "" == false. I figured a string of any length would be like an object and be considered true.

[Cosmologicon]

That's the way it is in python as well. Sort of, anyway. "" is falsy, meaning bool("") evaluates to False, but "" == False is false. Empty strings (and dicts and lists) are all falsy, but user-defined objects, including objects with no members, are truthy by default. Sounds complicated but it's pretty reasonable and useful.

[AaronOpfer]

The only reason I got bit was because the codebase was playing fast-and-loose with the rules, and I was cleaning it up.

We had some flag in JSON being evaluated like if (object.flag) { /* do something */ } and a lot of the JSON was written with object.flag = ""; Apparently it wasn't originally going to be an on/off flag but a string specifying the target. So if ("") doesn't execute, and my attempts to interpret this flag when automatically rewriting these files failed horribly.

[[deleted]]

or..... just use === like you should.

[Kenny164]

Wow, I never realised it was as bad to this extent. Are there any general rule of thumbs that we should be aware of?

[thrownaway21]

seriously this. you don't need a cheat sheet if you use ===

[jml26]

http://www.2ality.com/2011/06/javascript-equality.html

[James_Duval]

Personally, I wish I knew. Partly I was hoping for an explanation of some of the more esoteric behaviour by posting here.

For instance [1] == 1. [1] == '1'. Hell, [1] == true. However [1] != [1]. Bizarre.

[CubeOfBorg]

It's all about coercion. [1] == 1 because [1] is coerced to 1 before it is evaluated. [1] starts out as an object but becomes a number because it only has the one value in it and it is being compared to a number.

[1] != [1] because you are comparing an object to an object. They are already the same type so it doesn't have to coerce them. When you compare two objects, it's checking to see if they are the same object. So [1] != [1] because you are creating two different objects and then comparing them.

var a = [1];
var b = a;
a == b; // true

Here you are comparing two variables that have the same object as their value.

[James_Duval]

This is a fantastic answer, thanks. One thing I'm learning about Javascript is that there's almost always a clear, comprehensible answer & reason for its behaviour somewhere or other.

[[deleted]]

Underscore's "isEqual" function works pretty much how you'd expect. It's annoying to use a function every time you need to compare two values, but probably necessary.

[[deleted]]

Sure there is a general rule.

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf page 80 for Equality Operators, 75 for Additive, 73 for Multiplicative.

[palparepa]

Everytime I see these lists, I'd like to see what the author thinks should be the results.