Tengo curiosidad acerca de esto, ¿por qué los diseñadores de Kotlin pensarían que sería una buena idea eliminar la escritura explícita en Kotlin?
Para mí, escribir explícitamente no es un "dolor" para escribir en Java (o cualquier otro lenguaje fuertemente tipado): todos los IDE pueden ayudarme a escribir automáticamente mi variable.
Agrega una gran comprensión del código (es por eso que no me gustan los lenguajes de escritura débil, no tengo idea de qué tipo de variables estoy tratando).
Además, y este es mi principal problema con eso, hace que el código sea más propenso a errores.
Ejemplo :
Java: fácilmente identificado como una cadena, todo bien
String myPrice = someRepository.getPrice(); // Returns a String myTextView.setText(myPrice); Java: Fácilmente identificado como int, olor a código con setText()
int myPrice = someRepository.getPrice(); // Returns an int, code smell !! myTextView.setText(String.valueOf(myPrice)); // Problem avoidedKotlin: ????
val myPrice = someRepository.getPrice(); // What does it return ? myTextView.setText(myPrice); // Possible hidden bug with setText(@StringRes int) instead of setText(String) !!No tipear explícitamente en Kotlin es el mayor inconveniente en Kotlin imo. Trato de entender esta elección de diseño.
Realmente no estoy buscando "parches" para arreglar el ejemplo / evitar el olor del código presentado, trato de entender la razón principal detrás de la eliminación de la escritura explícita. Tiene que ser más que "menos tipeo / más fácil de leer". Solo elimina un par de caracteres (uno todavía tiene que escribir val / var ), y la escritura explícita en Kotlin agrega algunos caracteres de todos modos...
La tipificación estática sin tipificación explícita es, para mí, el peor de los casos para lidiar con errores ocultos / errores de espagueti: si una clase (digamos "Repositorio") cambia el tipo de devolución (de String a int , por ejemplo). Con escritura explícita, la compilación fallaría en la clase que llama "Repositorio". Sin tipeo explícito, la compilación puede no fallar y el tipo incorrecto de variable puede "viajar" a través de las clases y cambiar el comportamiento de las clases debido a su tipo. Esto es peligroso y no se detecta.
La solución es fácil; escriba explícitamente la variable. Pero estamos hablando de Kotlin, un lenguaje hecho para golfistas de código: las personas no escribirán explícitamente sus variables, ya que lleva aún más tiempo hacerlo en Kotlin que en Turtle-Java. ¡Ay!
En primer lugar: Kotlin tiene escritura estática . El compilador sabe exactamente qué tipo va o dónde viene. Y siempre eres libre de escribir eso, como
fun sum(a: Int, b: Int): Int { val c: Int = 1El punto es: puede escribir una gran cantidad de código que simplemente se basa en el hecho de que todo lo que hace se escribe estáticamente y también se verifica el tipo.
¿Realmente necesita saber si está sumando dos dobles o dos enteros o dos largos, cuando todo lo que "le importa" mirar es a + b ?
Al final, se trata de equilibrar diferentes requisitos. Omitir el tipo puede ser útil: menos código que los lectores humanos deben leer y comprender.
Por supuesto: si escribe código para que las personas recurran constantemente a su IDE para que el IDE les diga el tipo real e inferido de algo, ¡entonces convirtió una característica útil en un problema!
La verdadera respuesta aquí es: depende. He estado en muchas revisiones de código donde la gente de C++ discutió el uso de la palabra clave auto . Hubo muchas situaciones en las que el uso auto hizo que el código fuera mucho más fácil de leer y comprender, porque podía concentrarse en "lo que sucede con la variable", en lugar de mirar 1 minuto en su declaración, tratando de comprender su tipo. Pero también hubo ejemplos ocasionales en los que auto logró exactamente lo contrario, y una declaración "completamente mecanografiada" fue más fácil de seguir.
Y dado el comentario del OP: debes saber lo que estás haciendo en primer lugar. Significado: cuando escribe código, no solo invoca "cualquier" método que encuentre en algún objeto. Llamas a un método porque tienes que hacerlo. Es mejor que sepas lo que hace y lo que te devuelve. Estoy de acuerdo, cuando alguien tiene prisa, rápidamente asignas var y luego pasas esa cosa, eso podría generar errores. Pero para cada situación en la que var ayuda a crear un error, puede haber 10 incidentes en los que ayuda a escribir un código más fácil de leer. Como se dijo: la vida se trata de equilibrar.
Finalmente: los idiomas no deberían agregar funciones sin ningún motivo. Y la gente de Kotlin está equilibrando cuidadosamente las funciones que agrega. No agregaron la inferencia de tipos porque C++ la tiene. Lo agregaron porque investigaron cuidadosamente otros idiomas y encontraron útil ser parte del idioma. Cualquier característica del lenguaje puede ser mal utilizada. Siempre depende del programador escribir un código que sea fácil de leer y comprender. Y cuando sus métodos tienen firmas poco claras , por lo que "leer" sus nombres por sí solo no le dice qué está pasando, ¡entonces culpe al nombre del método, no a la inferencia de tipo!
Para citar JEP de inferencia de tipo de variable local de Java:
En una cadena de llamadas como:
int maxWeight = blocks.stream() .filter(b -> b.getColor() == BLUE) .mapToInt(Block::getWeight) .max();a nadie le molesta (o incluso nota) que los tipos intermedios
Stream<Block>eIntStream, así como el tipo de la lambda formalb, no aparecen explícitamente en el código fuente.
¿Estás molesto por eso?
si una clase (digamos "Repositorio") cambia el tipo de devolución (de String a int, por ejemplo). Con escritura explícita, la compilación fallaría en la clase que llama "Repositorio".
Si tiene sobrecargas como setText en su ejemplo, entonces
Repository repository = ...; myTextView.setText(repository.getFormerlyStringNowInt());tampoco fallará sin la inferencia de tipo. Para que falle, el estándar de su código debe exigir que el resultado de cada operación se asigne a una variable local, como en
Stream<Block> stream1 = blocks.stream(); Predicate<Block> pred = b -> { Color c = b.getColor(); return c == BLUE; }; Stream<Block> stream2 = stream1.filter(pred); ToIntFunction<Block> getWeight = Block::getWeight; IntStream stream3 = stream2.mapToInt(getWeight); int maxWeight = stream3.max();Y en este punto, hace que los errores sean más fáciles solo por la disminución de la legibilidad y la posibilidad de usar accidentalmente la variable incorrecta.
Finalmente, Kotlin no se creó en el vacío: los diseñadores pudieron ver que cuando C# introdujo la inferencia de tipo local en 2007, no condujo a problemas significativos. O podrían mirar a Scala, que lo tenía desde el principio en 2004; tenía (y tiene) muchas quejas de los usuarios, pero la inferencia de tipo local no es una de ellas.