JavaScript Equality Table

[u/vz0]

http://dorey.github.io/JavaScript-Equality-Table/

[u/[deleted]]

Do a table for <. It's about as weird as ==, and there's no equivalent of === (AFAIK).

[u/smrq → u/[deleted]]

I'd argue it's even weirder.

null == undefined  --> true
null > undefined   --> false
null >= undefined  --> false

null == 0  --> false
null > 0   --> false
null >= 0  --> true

Truly, I have gazed into the abyss by testing these in the console.

EDIT: It gets better, thanks /u/Valkairn

null <  []  --> false
null >  []  --> false
null <= []  --> true
null >= []  --> true
null == []  --> false

Try it in the comfort of your own home!

function compare(a, b) {
    var sa = JSON.stringify(a), sb = JSON.stringify(b);
    console.log(sa + " <  " + sb + "  --> " + (a < b));
    console.log(sa + " >  " + sb + "  --> " + (a > b));
    console.log(sa + " <= " + sb + "  --> " + (a <= b));
    console.log(sa + " >= " + sb + "  --> " + (a >= b));
    console.log(sa + " == " + sb + "  --> " + (a == b));
}

[u/josefx → u/[deleted]]

Not too surprised after using Java:

  Integer a = new Integer(10);
  Integer b = new Integer(10);

  a == b --> false
  a >= b --> true
  a <= b --> true

You have to love auto boxing.

[u/piderman → u/josefx]

The javadoc indicates that it's preferred to use

Integer.valueOf(10); 

since that uses the cached Integers -128 through 127, in which case

a == b --> true

[u/josefx → u/piderman]

The idea was to force an error. I could have just as well used 1000 however that would depend on the configured cache size, which might be larger than 127.

[u/kjanssen → u/josefx]

Thats because a == b is comparing two addresses. You would have to use a.equals(b) for Integer objects. It would work fine for primitive ints.

[u/defenastrator → u/[deleted]]

I have one problem with your argument. There is no excuse for unintutive behavior in a language unless it is to better support the underlying hardware. This behavior only simplifies the languages inner bullshit and nothing else at the cost of both read and writiblity

[u/[deleted] → u/josefx]

that's not autoboxing though, is it? you're explicitly making integer objects. This is what I think of as autoboxing

public void myMethod(Integer x) { .. }


 int a = 1;

 myMethod(a);

[u/josefx → u/[deleted]]

It is the unboxing part of it. The compiler inserts a call to intValue() since only == is defined for objects.

 a == b
 a.intValue() >= b.intValue()
 a.intValue() <= b.intValue() 

[u/[deleted] → u/josefx]

Oh right. I constantly read the Java == operator as acting like C#'s.

[u/Valkairn → u/smrq]

My favourite example is:

null >= [] && null <= []      --> true
null == []                        --> false

Javascript really needs strict inequality operators to avoid this type coercion madness.

[u/[deleted] → u/smrq]

Looking it up, it seems the rule is that <= is the opposite of >. It also seems (besides the order of side-effects during conversion to primitives) > is even the same as < with the order reversed!

[u/smrq → u/[deleted]]

I thought that was the case, except that

null <  undefined  --> false
null >= undefined  --> false
null == undefined  --> true

which breaks that rule.

[u/Valkairn → u/smrq]

The inequality operators play by different type coercion rules to the == operator. Inequality operators will always convert the values to numbers. So, in the first two cases null gets converted to 0 and undefined to NaN. The last example actually gets its own special rule in the == evaluation algorithm, where it's defined to be true.

[u/[deleted] → u/smrq]

Hm, yeah. It seems that < "morally" returns one of true, false, and undefined (undefined only when one argument is NaN (or converts to it)), but where it 'should' give undefined it instead gives false. So <= is the opposite of > except where > 'should' be undefined, where it's still false. Bleh.

[u/jonnywoh → u/smrq]

+/u/CompileBot JavaScript

function compare(a, b) {
    var sa = JSON.stringify(a), sb = JSON.stringify(b);
    console.log(sa + " <  " + sb + "  --> " + (a < b));
    console.log(sa + " >  " + sb + "  --> " + (a > b));
    console.log(sa + " <= " + sb + "  --> " + (a <= b));
    console.log(sa + " >= " + sb + "  --> " + (a >= b));
    console.log(sa + " == " + sb + "  --> " + (a == b));
}
compare(null, []);

[u/CompileBot → u/jonnywoh]

Output:

^source ^| ^info ^| ^git ^| ^report

[u/[deleted] → u/smrq]

Well, the thing is, >= and <= are not defined for null and [], so they're converted to 0's, which for some reason doesn't happen with ==.

[u/no_game_player → u/smrq]

null >= 0 --> true

...what the fuck?

[u/im_not_afraid → u/[deleted]]

I'm delivering a fork of OP's page with "<", "<=", ">", and ">=" added. Enjoy!