Hacker News Reader

Comment by twerquie | Hacker News Reader

So, use triple-equals when you don't want type coercion?

My favorite bit is where all of these are true:

    '1' == 1 
    '1' == [1]
    '1' == true  
    1 == [1]  
    1 == true  
    [1] == true

But this is false:

    [1] == [1]

Why would it be true? Two different instances of an object don't equal in JS. It compares identity, not value, when dealing with non-value types.

I think the point is that it's interesting that a bunch of textually-different things are considered equal, but the one textually identical pair are considered not equal.

Because equality should be transitive. If a == b and b == c, then it should be the case that a == c.

[1] == 1 and 1 == [1], so it should be the case that [1] == [1].

Just because it's what happens when you apply the rules of the language doesn't mean it actually makes sense.

> Why would it be true?

It is funny that you are asking why would [1] == [1] possibly considered to be true.

Let's see in a language with a sane and consistent typing system like Python:

       In [1]: [1]==[1]
       Out[1]: True

Ok, let's do a crazy language from Sweden also with dynamic types but which are sane and consistent, like Erlang:

       1> [1] == [1].
       true

Surely it will be broken in Ruby:

         irb(main):001:0> [1] == [1]
         => true

Nah clearly it should be false, these crazy languages just haven't heard about objects and identities and such.

Why are you being a dick? He explained the difference accurately - JS compares objects as individual objects. Arrays are objects. The other languages you cited do not work that way.

Here's another example:

    4 == 4 // true
    a = new Number(4);
    b = new Number(4);
    a == b // false
    a == a // true
    a.valueOf() // 4
    b.valueOf() // 4
    a.valueOf() == b.valueOf() // true

And if this isn't clear yet:

    a = {}
    b = {}
    a == a // true
    a == b // false

Rather his tone of "Why would it be true?" sounded dick-ish. As in "How could possibly one consider [1] == [1] be true, are you crazy? It should obviously be false".

So I gave a couple of examples from other dynamic languages where the the sane behavior is "obvious".

I am not being a dick I am saying the language is broken. Explaining the historical context or the internal implementation of it doesn't make it unbroken. Like one can explain why COBOL uses this construct or that and how it came to be, doesn't make COBOL better or more appealing. One of course might not have a choice and be stuck using it but lying to oneself about how awesome it is, is not necessary.

> The other languages you cited do not work that way.

The don't, and I like how they work better.

Now whether one has a choice to use or not use JS is a different topic. Usually there is no choice on the client side. But somehow extolling Javascript typing rules as being sane, making sense, or as someone below put it "brilliant" is a bit silly.

No, he didn't ask it like that at all. You're putting words in his mouth instead of reading the sentence in the context of the two sentences that followed it, which made it a completely reasonable question.

A better rule is to use triple-equals always, and manually coerce if you really mean it.

This is a dangerous rule; if you put this rule in the hands of a programmer who is not used to Javascript and doesn't really understand the type system, you can just as easily run into problems.

This is because you require the programmer to always understand the output (and defaults) of every call made. Sometimes it's undefined. Sometimes it's null. Sometimes it's empty string. This takes experience.

Example, the default for getAttribute is null, but an undefined property is undefined:

  document.body.getAttribute("test"); // null
  document.body.test; // undefined

Except if it's a special property, then getAttribute might still be null, but the property empty string:

  var input = document.createElement("input");
  input.getAttribute("value"); // null
  input.value; // ""

Remember, "" !== null and null !== undefined.

That only solves part of the problem. Coercion also happens for other operators, which ought to have at least had === equivalents. I.e.

   5 + (10 * [2]) + (9 + [1/'']) // 259Infinity
   5 ~+ (10 ~* [2]) ~+ (9 ~+ [1 ~/ '']) // throw exception

Yes, or you can use CoffeeScripts which automatically translates == into ===

Yes, highly recommended. Just look at that chart, insanity!

Reply on news.ycombinator.com