let y also: el objeto como argumento

Que let y also entreguen el objeto como argumento en lugar de como receptor parece un detalle menor de la firma, pero es la propiedad que determina en qué situaciones son la elección correcta. Un argumento tiene nombre, y tener nombre significa poder renombrarlo cuando hay anidamiento, poder pasarlo a otra función sin ambigüedad y no competir jamás con el this de la clase que rodea al bloque. A cambio, cada acceso al objeto cuesta un identificador y un punto, de modo que el bloque se vuelve ruidoso en cuanto hay muchos accesos. Esa asimetría define su terreno natural: bloques cortos, donde el objeto aparece una o dos veces, y donde lo importante no es tocar muchos miembros sino hacer una sola cosa con el valor entero. Dentro de ese terreno, la diferencia entre las dos es únicamente el eje del retorno, y de esa diferencia salen dos usos que no se parecen en nada.

let: transformar y acotar

La firma de let dice que recibe el objeto como argumento y devuelve lo que produzca el bloque. Su función primaria es, por tanto, la transformación: convertir un valor en otro dentro de una expresión, sin nombrar el intermedio y sin romper la cadena de llamadas. El segundo uso, menos comentado y a menudo más valioso, es el de acotar el ámbito de un valor: lo que entra en el bloque deja de existir al salir, y eso convierte una variable local de vida larga en un identificador confinado a tres líneas.

// Transformar dentro de una cadena
val iniciales = nombreCompleto
    .split(" ")
    .let { partes -> partes.joinToString("") { it.first().uppercase() } }

// Acotar: el intermedio no sobrevive al bloque
val resumen = cargarInforme(id).let { informe ->
    "${informe.titulo} con ${informe.filas.size} filas"
}

Nótese en el primer ejemplo el argumento renombrado a partes. Cuando dentro del bloque de let hay otra lambda que también usa it, renombrar deja de ser una cortesía y pasa a ser obligatorio para que el código sea legible, porque el it interno oculta al externo sin que el compilador diga nada. Es la primera manifestación del problema de anidamiento que la última lección del nivel trata en profundidad, y la regla práctica es sencilla: en cuanto haya dos lambdas encajadas, ninguna de las dos debería seguir llamándose it.

let en el camino de los nulables

El uso que hizo célebre a let no es la transformación sino su combinación con la llamada segura. Escrito como ?.let, el bloque se ejecuta solo cuando el receptor no es nulo, y dentro del bloque el argumento tiene ya el tipo no nulable, sin necesidad de comprobación ni de conversión. La expresión completa es nulable, porque su valor es nulo cuando el receptor lo era, y eso permite rematarla con un operador de elvis que provee la alternativa.

val longitud: Int = texto?.let { it.trim().length } ?: 0

// Encadenar varias etapas que pueden desaparecer
val ciudad: String? = usuario
    ?.direccionPrincipal
    ?.let { normalizar(it) }
    ?.takeIf { it.isNotBlank() }

Este idioma tiene una virtud que conviene nombrar con precisión, porque explica por qué se prefiere a la alternativa con if. Una comprobación con if sobre una propiedad mutable no habilita el smart cast, ya que el compilador no puede garantizar que el valor no cambie entre la comprobación y el uso; la llamada segura sí, porque evalúa el receptor una única vez y pasa esa evaluación al bloque como argumento inmutable. Por eso ?.let es la salida idiomática cuando el valor procede de una propiedad var, de una propiedad de otro módulo o de código Java, mientras que sobre un val local un if ordinario suele leerse mejor.

class Sesion { var token: String? = null }

fun usar(s: Sesion) {
    if (s.token != null) enviar(s.token)      // no compila: sin smart cast
    s.token?.let { enviar(it) }               // correcto
}

flowchart LR
A[Valor posiblemente nulo] --> B{Llamada segura}
B -- Es nulo --> C[Toda la expresion vale nulo]
B -- No es nulo --> D[Entra al bloque ya como tipo definido]
D --> E[Transformacion dentro de let]
C --> F[Elvis aporta la alternativa]
E --> G[Resultado final]
F --> G

Hay un matiz de evaluación que conviene tener presente porque se manifiesta en cadenas largas. La llamada segura no evalúa nada de lo que viene después cuando el receptor es nulo, de modo que un bloque con efectos laterales colocado detrás de un eslabón apagado simplemente no ocurre. Eso es deseable la mayoría de las veces y sorprendente cuando el bloque contenía un registro que alguien esperaba ver siempre. La regla que evita la sorpresa es no colocar detrás de una llamada segura ningún efecto que deba ejecutarse en ambos casos.

also: intervenir sin alterar

also recibe el objeto como argumento igual que let, pero devuelve el objeto en lugar del resultado del bloque. Esa transparencia lo convierte en el punto de intervención de una cadena: todo lo que ocurre dentro es efecto lateral por definición, porque el valor calculado se descarta. Registrar, validar, medir, notificar y depurar son sus casos legítimos, y todos comparten la propiedad de poder eliminarse sin cambiar ni el tipo ni el valor de la expresión.

val pedido = construirPedido(carrito)
    .also { log.debug("pedido construido: {}", it.id) }
    .also { require(it.lineas.isNotEmpty()) { "pedido vacio" } }
    .let { aplicarDescuentos(it) }

fun guardar(u: Usuario): Usuario =
    repositorio.insertar(u).also { metricas.incrementar("usuarios.creados") }

El nombre está bien elegido y conviene leerlo literalmente: la cadena hace lo suyo y además hace esto. Esa lectura sugiere la prueba que decide si el uso es correcto, y es la prueba de la supresión: si al borrar el bloque el resto del programa sigue siendo válido en tipos y en semántica principal, also es la función adecuada. Si al borrarlo se pierde algo que el flujo necesita, entonces el bloque no era un añadido sino una etapa, y una etapa se escribe con la función que devuelve su resultado.

Los usos degenerados de ambas

Hay tres patrones que aparecen con insistencia en las revisiones de código y que conviene reconocer de un vistazo. El primero es el let sobre un valor no nulable cuyo bloque llama a una función con it: es una llamada normal con envoltorio. El segundo es el also cuyo bloque modifica el objeto en lugar de observarlo, que es exactamente el trabajo de apply y que engaña al lector porque el nombre promete un añadido y entrega una mutación. El tercero, más sutil, es la cadena de tres o más ?.let consecutivos, donde cada eslabón puede apagar el resto y el lector acaba sin saber cuál de los pasos produjo el nulo final; ahí la construcción honesta suele ser una función con salidas anticipadas, o el uso de runCatching si lo que se está modelando en realidad es un fallo y no una ausencia.

// Degenerado: envoltorio sin funcion
val n = texto.let { it.length }        // texto.length

// Degenerado: also que muta
val u = Usuario().also { it.activo = true }   // deberia ser apply

// Sospechoso: tres apagados en serie sin diagnostico posible
val v = a?.let { f(it) }?.let { g(it) }?.let { h(it) }

El tercer patrón merece un comentario adicional porque su corrección no es mecánica. Una cadena de llamadas seguras encadenadas es perfectamente legítima cuando todos los eslabones representan la misma ausencia, es decir, cuando el nulo final significa siempre lo mismo para quien recibe el resultado. Deja de serlo en cuanto los eslabones representan condiciones distintas, porque entonces la expresión ha comprimido varias preguntas en una sola respuesta y ha perdido la información de cuál falló. La señal más fiable de que se ha cruzado esa línea es tener que añadir un registro dentro de la cadena para averiguar dónde se apagó: si hace falta instrumentar la expresión para entenderla, la expresión ya era demasiado larga.

// Legitimo: un unico significado para la ausencia
val ciudad = usuario?.direccion?.ciudad?.nombre

// Ilegitimo: tres condiciones distintas comprimidas en un solo nulo
val listo = entrada?.let { validar(it) }?.let { autorizar(it) }?.let { firmar(it) }