Why doesn't JavaScript have strict greater/less than comparison operators?

While JavaScript's type-strict comparison operators (===, !==) are nice, it doesn't have corresponding strict comparisons for greater/less than.

var x = 10;


x <= 20;    // true
x <= '20';    // true
x <== 20;   // true (or would be, if JS had such an operator)
x <== '20'; // false (ditto)

Why not? I ask this question fully expecting the answer to be "uh, because it doesn't", but I'm asking anyway, in case there's an interesting and/or disheartening historical reason for such operators being omitted.

21830 次浏览
小开

Since a === b is a shorthand for typeof a == typeof b && a == b, you can use this expansion for inequalities: typeof a == typeof b && a <= b for example.

小开
最佳答案

I can only guess-

If
a === b is false, then
a !== b is true. always.

But, this implication wouldn't hold for <==

If
x <== 20 is false, we cannot infer the result of x >== 20 because it might have been false due to type check, or the relation check.

I think that's slightly confusing, although there's plenty of things in the language that are much worse (type coercion in general, to name one).

However, I think a strict < or > would behave consistently.

小开

I'm not sure there is an answer to your question. My guess is, the intended use is for comparing numbers to strings (and maybe booleans). It actually works for those cases, as the non-strict equality operator does. Anything else is subject to arbitrary type coercion rules anyway. What would be the "correct" output of [] < {}? false? Maybe undefined? Note that the types don't even need to be different, ({foo: 1}) < {bar : 2} also doesn't make any sense.

In my opinion, they (Brendan Eich, and later the ECMAScript committee) just decided to trust that the developers would only compare things that make sense comparing. Or didn't even consider that developers would try crazy comparisons. Creating extra operators for comparison would only clutter the language. And don't forget comparisons are not the only pitfalls when dealing with type coercion, there's also addition, subtraction, etc. So I guess they just decided to be true to their decision of allowing operations between different types. They thought that would help people when they know what they're doing, but maybe didn't anticipate all the confusion that arose from that.

小开

To show why it doesn't make sense to have it, consider instead...

var x = 10
var less = (x <= 5)

Now, both

x <== 5

and 

x <== '5'

would be false, but for different reasons. In the first instance, you could use the assumption that x > 5, but not in the latter case. To avoid false assumptions it is better to use === or !== first and then comparison after.

小开

I'd say that the problem is that strict equality can be well defined for different types (not the same type, then not equals), but relational operators can not be well defined for different types.

Assume we define a strict comparator a <== b to be typeof a == typeof b && a <= b. And the same for a >== b. Then we compare a = "3" and b = 3 and the results are a <== b false, a >== b false and a === b false. Congratulations, you just created a paradox!

Such strict comparator would still mess up things like sorting algorithms, or comparing unexpected values. For example:

for (var i; i <== list.count; i++) {
doStuff(i);
}

Note that the example is mistakenly using list.count instead of list.length, which will just return undefined, which would just return false when compared to i <== undefined, so the for loop would be entirely skipped to the surprise of the programmer.

It would me much better if JavaScript raised an error on list.count for Undefined Property, and also if comparing different types.

That's all I can say, comparing across types should raise an exception, just like any other decent language out there. But it doesn't.

This means, that the actual practical solution is to start using preprocessors, or just say "Oh well" and keep typing JavaScript ¯\_(ツ)_/¯


提交答案