Kotlin, parte 2: (not so) typesafe null y otras monerías

Una característica importante de Kotlin es que maneja seguridad en nulos. Esto es algo que varios lenguajes han estado implementando últimamente, porque ahorra muchos dolores de cabeza.

Normalmente, una variable de cualquier tipo que sea objeto, acepta  . En Kotlin no es así; para que una variable acepte null, se necesita especificar de esa forma. Esto no compila:

Porque   ha sido definida como de tipo  , y no acepta nulos. Para que acepte nulos, se tiene que definir así:

Los tipos opcionales se pueden usar en parámetros de funciones, tipos de retorno y declaraciones locales.

Cuando se tiene un valor que puede ser null, no se puede usar de manera directa. Hay que verificar que el objeto exista; esto se puede lograr de varias formas:

Esto nos evita dolores de cabeza porque en vez de tener que lidiar con NullPointerException en tiempo de ejecución, estos errores se detectan en tiempo de compilación. Sin embargo, Kotlin tiene un gran problema con esto: integrado con la seguridad de nulos, viene un mecanismo para desactivarla por completo: Si se agrega una doble admiración al final de una variable opcional, el compilador deshabilita las verificaciones de nulos y se porta como lo haría el compilador de Java, permitiendo que sea nulo donde sea:

Es decepcionante que hayan incluido ese operador, por una simple razón: La gente que llega a Kotlin, no está acostumbrada a tener que verificar que algo no sea nulo y les va a fastidiar tener que estar validando todo al principio, porque no están acostumbrados; por lo tanto, van a usar la doble admiración por todos lados, anulando así el beneficio de dichas verificaciones.

Smart casting

Otra característica buena de Kotlin, es una que le llaman smart casting. Consiste en evitar hacer un cast innecesario, como en Java. Por ejemplo, esto es común en Java:

Esto lo he dicho varias veces: cuando hacemos un cast, le estamos diciendo al compilador "quítate, yo sé lo que hago". Y por supuesto, muchas veces no sabemos lo que estamos haciendo y cometemos errores en el código, que como el compilador ya no los valida, pues se van a tiempo de ejecución.

Kotlin alivia este tipo de problemas con los smart casts:

En este ejemplo,   es de tipo   (el tipo raíz en Kotlin, que no es lo mismo que el   de Java), sin embargo al tener la condición donde se verifica si es de tipo String, el bloque de código interno al   ya considera que   es de tipo String. De ese modo, no es necesario hacer un cast.

Esta es una característica que Ceylon también tiene, sin embargo, en Ceylon por tener tipos unión e intersección, esto es más poderoso y elimina por completo la necesidad de hacer casts, por lo que no se permiten (sólo se permiten upcasts, es decir, hacer casts a tipos más generales, pero no más específicos). Sin embargo, el sistema de tipos de Kotlin, al ser más limitado (prácticamente igual al de Java, con excepción de que todo es un objeto, no hay tipo nativos, lo cual es bastante bueno) necesita que haya casts para algunos casos especiales, sin embargo el lenguaje debe permitir hacer cast en donde sea. Por lo tanto se puede hacer algo así:

Ese código va a arrojar una   al ejecutarse. El problema que se tiene en Java, fue migrado a Kotlin. Y los programadores que usen Kotlin por primera vez, si no investigan bien las características del lenguaje, van a hacer casts donde no se necesitan, y por lo tanto es posible que hagan un cast mal y tengan los mismos problemas que en Java.

Data classes

Kotlin tiene una cosa que tomaron prestada de Scala: las data classes. Son similares a los Java beans, con la diferencia de que por default son inmutables y por tanto tienen un constructor que recibe todos los valores para sus propiedades. Las data classes no necesitan un cuerpo; solamente se declara el nombre de la clase y en el constructor se declaran todas sus propiedades.

Las data classes son un poco más poderosas que los Java beans porque automágicamente se les agrega una implementación de   que despliega los valores de todas sus propiedades, así como una implementación de   que compara todas las propiedades de ambos objetos para considerarlos iguales. Pero no implementa  ...

Por cierto, para instanciar objetos en Kotlin no se requiere de  ; simplemente se invoca el constructor como si fuera una función (al igual que en Ceylon).

Se pueden definir valores por defecto para parámetros, siempre y cuando se tengan al final todos los parámetros con valores por defecto:

Invocaciones por nombre

Las invocaciones por nombre son muy útiles cuando se tienen métodos, funciones o constructores con muchos parámetros, pues mejoran la legibilidad porque queda muy claro qué argumentos se pasan, sin tener que recurrir a la documentación, e incluso se puede reordenar los argumentos en caso que no tenga mucho sentido como están declarados los parámetros:

Destructuring

Creo que esto lo podríamos traducir como "desestructuración". Esto es algo muy simple pero muy conveniente y se entiende mejor con un simple ejemplo, usando una clase que ya definimos anteriormente:

Otro ejemplo, con ciclos y mapas:

Lo anterior es bastante conveniente, mucho más breve que el equivalente en Java  . Sin embargo, puede resultar algo desconcertante la irregularidad en la sintaxis: para declarar las entradas del mapa se usa el operator  , mientras que en el ciclo se usa la sintaxis  ; un programador novato seguramente intentaría primero escribir  , y los mensajes de error del compilador en este caso no ayudan en nada (pruébenlo ustedes mismos para darse cuenta de los errores que arroja al escribir esa alternativa y sus variantes con paréntesis).

En la tercera parte de esta serie, trataré un tema un poco más complejo: la sobrecarga de operadores, y los métodos de extensión.

Ir a la tercera parte de la serie