En general, todas las decisiones de diseño en Kotlin siente como que es tanto grande en su propio derecho y ofrece una buena transición desde Java. Como desarrollador de Java puede empezar a programar en ella pensando en Kotlin como más concisa de Java con menos repetitivo, a continuación, pasar sin problemas en los aspectos más avanzadas como la programación funcional.
Lo que estoy preguntando acerca sin embargo es la razón por sus diseñadores decidieron hacer ==comportan de forma idéntica a equalsy luego introducir ===para la comprobación de igualdad referencial. Me puedo imaginar tratando de traer a otros desarrolladores de Java en el redil, que vean su código Kotlin y pensando "oh no, hay verificación de referencias por todo el lugar donde debe ser igual a una llamada!"
¿Cuál es el proceso de pensamiento para alejarse de la convención de Java aquí? Sólo para que quede claro, entiendo perfectamente bien cuál es la diferencia entre ==o equalsy ===en Kotlin, me pregunto por qué.
La razón principal es, probablemente, que la igualdad de objeto se comprueba con más frecuencia que la identidad del objeto, por lo que debe ser al menos tan fácil.
No he visto una declaración definitiva sobre esto. Pero hay un puntero en el libro Kotlin En Acción , por miembros del equipo de Kotlin. Sección 4.3.1, introduciendo el ==operador, se describe en primer comparaciones de Java y dice que:
en Java, está la práctica bien conocida de llamar siempre
equals, y ahí está el problema bien conocido de olvidarse de hacerlo.
En Java, comprobando la identidad del objeto es fácil:
if (firstObj == secondObj)
Pero la igualdad objeto de cheques es más largo y más bien menos clara:
if (firstObj.equals(secondObj))
- o, más bien, si no se quiere correr el riesgo de una NullPointerException:
if ((firstObj == null) ? (secondObj == null) : firstObj.equals(secondObj))
Puede ver la cantidad de más de un dolor que es escribir, y para hacerlo bien. (Especialmente cuando uno de esos objetos es una expresión con efectos secundarios ...)
Por lo que es fácil olvidar la diferencia, o no ser molestado, y utilizar ==en su lugar. (Lo cual es probable que cause errores que son sutiles, difíciles de detectar, y morder de manera intermitente.)
Kotlin, sin embargo, hace la operación más común la más fácil: la ==igualdad operador comprueba objeto utilizando equals(), y se encarga de comprobar nulo también. Corrige este de Java 'problema de olvidarse de hacerlo'.
(Y aunque la interoperabilidad con código Java era claramente un objetivo importante, JetBrains no se limitan a tratar de mirar como Java; Kotlin toma prestado de Java cuando sea posible, pero no tiene miedo a cambiar las cosas para mejor Se puede ver que en. el uso de valy vary posterior tipos de declaraciones, los distintos valores predeterminados para determinación del alcance y la apertura, la varianza diferentes maneras de tratar, y c.)
Una de las motivaciones de Kotlin era fijar muchos de los problemas en Java. (De hecho, JetBrains' comparación de las lenguas comienza enumerando 'Algunas cuestiones tratadas en Java Kotlin'.) Por lo tanto, parece probable que esta es una de las principales razones detrás del cambio.