utilizan - operadores logicos javascript w3schools
¿Por qué JavaScript no tiene operadores estrictos de mayor/menor que los de comparación? (5)
Si bien los operadores de comparación de tipo estricto de JavaScript ( === !== ) son agradables, no tiene comparaciones estrictas correspondientes para mayor / menor que.
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)
Por qué no? Hago esta pregunta esperando que la respuesta sea "eh, porque no es así", pero lo estoy preguntando de todos modos, en caso de que exista una razón histórica interesante y / o desalentadora para que se omitan dichos operadores.
Como a === b es una abreviatura para typeof a == typeof b && a == b , puede usar esta expansión para desigualdades: typeof a == typeof b && a <= b por ejemplo.
No estoy seguro de que haya una respuesta a tu pregunta. Mi suposición es que el uso previsto es para comparar números con cadenas (y tal vez booleanos). En realidad funciona para esos casos, como lo hace el operador de igualdad no estricta. Cualquier otra cosa está sujeta a reglas de coerción de tipo arbitrario de todos modos. ¿Cuál sería la salida "correcta" de [] < {} ? false ? ¿Tal vez undefined ? Tenga en cuenta que los tipos ni siquiera necesitan ser diferentes, ({foo: 1}) < {bar : 2} tampoco tiene ningún sentido.
En mi opinión, ellos (Brendan Eich, y más tarde el comité de ECMAScript) simplemente decidieron confiar en que los desarrolladores solo compararían las cosas que tienen sentido comparando. O incluso no considera que los desarrolladores intenten hacer comparaciones locas. La creación de operadores adicionales para la comparación solo complicaría el lenguaje. Y no olvide que las comparaciones no son las únicas trampas cuando se trata de la coerción de tipo, también hay suma, resta, etc. Así que supongo que decidieron ser fieles a su decisión de permitir operaciones entre diferentes tipos. Pensaron que eso ayudaría a las personas cuando supieran lo que estaban haciendo, pero quizás no previeron toda la confusión que surgió de eso.
Para mostrar por qué no tiene sentido tenerlo, considere en su lugar ...
var x = 10
var less = (x <= 5)
Ahora, ambos
x <== 5
y
x <== ''5''
sería falso, pero por diferentes razones. En la primera instancia, podría usar la suposición de que x> 5, pero no en el último caso. Para evitar suposiciones falsas, es mejor usar === o! == primero y luego comparar después.
Solo puedo adivinar-
Si
a === b es falso, luego
a !== b es verdadero. siempre .
Pero, esta implicación no sería válida para <==
Si
x <== 20 es falso, no podemos inferir el resultado de x >== 20 porque podría haber sido falso debido a la comprobación de tipo o la comprobación de relación.
Creo que es un poco confuso, aunque hay muchas cosas en el idioma que son mucho peores (escribe coerción en general, por nombrar una).
Sin embargo, creo que un < o > estricto se comportaría de manera consistente.
Yo diría que el problema es que la igualdad estricta puede definirse bien para diferentes tipos (no del mismo tipo, entonces no es igual), pero los operadores relacionales no pueden definirse bien para diferentes tipos.
Supongamos que definimos un comparador estricto a <== b para ser typeof a == typeof b && a <= b . Y lo mismo para a >== b . Luego comparamos a = "3" yb = 3 y los resultados son a <== b falso, a >== b falso y a === b falso. ¡Felicidades, acabas de crear una paradoja!
Un comparador tan estricto seguiría estropeando cosas como clasificar algoritmos o comparar valores inesperados. Por ejemplo:
for (var i; i <== list.count; i++) {
doStuff(i);
}
Tenga en cuenta que el ejemplo está utilizando erróneamente list.count lugar de list.length , que simplemente devolverá undefined , que simplemente devolverá false en comparación con i <== undefined , por lo que el bucle for se omitirá por completo para sorpresa del programador .
Sería mucho mejor si JavaScript list.count un error en list.count para Propiedad no list.count , y también si comparas diferentes tipos.
Eso es todo lo que puedo decir, la comparación de todos los tipos debería generar una excepción, al igual que cualquier otro lenguaje decente por ahí. Pero no es así
Esto significa que la solución práctica real es comenzar a usar preprocesadores, o simplemente decir "Oh bien" y seguir escribiendo JavaScript ¯/_(ツ)_/¯