6 ms·

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 fals

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]

TazeTSchnitzel 13y ago
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.
- rdtsc 13y ago
  > 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.
  - artursapek 13y ago
    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
    - rdtsc 13y ago
      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.
      - artursapek 13y ago
        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.
- baddox 13y ago
  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.
- mikeash 13y ago
  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.

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]

TazeTSchnitzel 13y ago

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.

rdtsc 13y ago
> 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.
- artursapek 13y ago
  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
  - rdtsc 13y ago
    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.
    - artursapek 13y ago
      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.
baddox 13y ago
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.
mikeash 13y ago
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.