Хотя JavaScript-операторы строгого сравнения типов (===, !==) хороши, он не имеет соответствующих строгих сравнений для больше / меньше чем.

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)

Почему бы нет? Я задаю этот вопрос, полностью ожидая, что ответ будет "ну, потому что это не так", но я все равно задаю вопрос, если есть интересная и / или обескураживающая историческая причина, по которой такие операторы опущены.

64
mwcz 26 Янв 2013 в 05:58

4 ответа

Лучший ответ

Я могу только догадываться

Если
a === b ложно, тогда
a !== b верно. < Сильный > < EM> всегда .

Но это значение не будет иметь место для <==

Если
x <== 20 ложно, мы не можем вывести результат x >== 20 потому что это могло быть ложно из-за проверки типа или проверки отношения.

Я думаю, что это слегка сбивает с толку, хотя в языке есть много вещей, которые намного хуже (например, принуждение типов в целом).

Однако я думаю, что строгие < или > будут вести себя последовательно.

25
Timo Tijhof 11 Фев 2015 в 08:45

Поскольку a === b является сокращением для typeof a == typeof b && a == b, вы можете использовать это расширение для неравенств: typeof a == typeof b && a <= b, например.

22
Niet the Dark Absol 26 Янв 2013 в 02:00

Я бы сказал, что проблема в том, что строгое равенство может быть четко определено для разных типов (не одного и того же типа, а не для равных), но реляционные операторы не могут быть четко определены для разных типов.

Предположим, мы определяем строгий компаратор a <== b как typeof a == typeof b && a <= b. И то же самое для a >== b. Затем мы сравниваем a = "3" и b = 3, и результаты являются a <== b ложными, a >== b ложными и a === b ложными. Поздравляю, вы только что создали парадокс!

Такой строгий компаратор все равно испортит такие вещи, как алгоритмы сортировки или сравнение неожиданных значений. Например:

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

Обратите внимание, что в примере ошибочно используется list.count вместо list.length, который просто вернет undefined, который просто вернет false по сравнению с i <== undefined, поэтому цикл for будет полностью пропущен к удивлению программиста.

Было бы намного лучше, если бы JavaScript вызывал ошибку list.count для неопределенного свойства, а также при сравнении разных типов.

Это все, что я могу сказать, сравнение между типами должно вызвать исключение, как и любой другой приличный язык. Но это не так.

Это означает, что реальное практическое решение состоит в том, чтобы начать использовать препроцессоры или просто сказать «Ну хорошо» и продолжать вводить JavaScript ¯\_(ツ)_/¯

0
tothemario 6 Май 2016 в 03:02

Я не уверен, что есть ответ на ваш вопрос. Я предполагаю, что предполагаемое использование для сравнения чисел со строками (и, возможно, булевы). Это действительно работает для тех случаев, как оператор нестрого равенства. В любом случае все остальное подпадает под действие правил приведения произвольного типа. Каким будет «правильный» вывод [] < {}? false ? Может быть undefined? Обратите внимание, что типы даже не должны быть разными, ({foo: 1}) < {bar : 2} также не имеет никакого смысла.

По моему мнению, они (Брендан Эйч, а затем комитет ECMAScript) просто решили поверить, что разработчики будут сравнивать только то, что имеет смысл сравнивать. Или даже не считал, что разработчики будут пытаться сравнивать сумасшедшие. Создание дополнительных операторов для сравнения только загромождает язык. И не забывайте, что сравнения - не единственные подводные камни при работе с приведением типов, есть также сложение, вычитание и т. Д. Поэтому я думаю, они просто решили быть верными своему решению о разрешении операций между различными типами. Они думали, что это поможет людям, когда они знают, что делают, но, возможно, не ожидали всей путаницы, которая возникла из-за этого.

5
bfavaretto 26 Янв 2013 в 03:28