Sintaxis y semántica: declarar, proveer y resolver un contexto

La sintaxis de los parámetros de contexto cabe en una línea y la semántica cabe en tres reglas, lo cual es engañoso, porque cada una de esas reglas es el resultado de descartar una alternativa que parecía razonable. Un parámetro de contexto se declara delante de la función, lleva nombre obligatorio, no se convierte en receptor implícito y se resuelve por tipo a partir de lo que haya disponible en el ámbito de la llamada. Ese conjunto de decisiones produce un mecanismo que se comporta como un parámetro normal en todo salvo en una cosa: quien llama no lo escribe. Esta lección construye el modelo mental completo, desde la declaración hasta el error de compilación, y deja claro qué está garantizado y qué no.

Declarar y usar

La declaración se escribe delante del resto de la firma, con la palabra clave context seguida de una lista de pares de nombre y tipo entre paréntesis. Cada par es un parámetro de contexto: tiene nombre, tiene tipo y se comporta dentro del cuerpo exactamente igual que un parámetro de valor, con la única diferencia de que ningún sitio de llamada lo menciona.

interface Logger {
    fun info(mensaje: String)
    fun error(mensaje: String, causa: Throwable? = null)
}

context(log: Logger)
fun procesar(pedido: Pedido): Respuesta {
    log.info("procesando ${pedido.id}")     // hay que nombrarlo
    return Respuesta(pedido.total)
}

Detente en la tercera línea del cuerpo, porque ahí está la decisión central del diseño. El servicio se usa escribiendo log.info, con el nombre delante, y no simplemente info. Un parámetro de contexto no es un receptor implícito: no aporta sus miembros al ámbito, no responde a this y no compite con nada en la resolución de nombres. La consecuencia inmediata es que declarar tres contextos no llena el autocompletado con los miembros de tres tipos, y que renombrar un método de Logger no puede romper silenciosamente un cuerpo que llamaba a otra cosa con el mismo nombre. Esta es la diferencia esencial respecto del diseño anterior, y la tercera lección del nivel cuenta por qué costó tanto llegar a ella.

Se pueden declarar varios contextos a la vez, cada uno con su nombre, y combinarlos con un receptor de extensión y con parámetros de valor ordinarios. El orden de lectura de una firma completa es el que sugiere la escritura: primero lo que viene del ámbito, luego el sujeto de la operación, luego los argumentos que quien llama decide.

context(log: Logger, tx: Transaccion)
fun Pedido.confirmar(cupon: Cupon?): Confirmacion {
    log.info("confirmando $id")             // this es el Pedido, no el Logger
    tx.registrar(this)
    return Confirmacion(id, cupon)
}

Cuando un contexto solo hace falta para propagarlo a una llamada más profunda y su cuerpo nunca lo menciona, se puede declarar con el nombre _. Es una declaración anónima: el valor sigue existiendo, sigue exigiéndose en el sitio de llamada y sigue pasándose hacia abajo, pero el cuerpo no puede referirse a él. Sirve para documentar la exigencia sin introducir un identificador que nadie usa.

context(_: Transaccion)
fun eliminar(id: String) = repositorio.borrar(id)   // exige la transaccion sin nombrarla

Cómo se resuelve en el sitio de llamada

Quien llama a procesar no escribe ningún logger. Lo que hace el compilador es buscar, en el ámbito de esa llamada, un valor cuyo tipo sea el requerido o un subtipo suyo, y pasarlo. El conjunto de valores elegibles se llama argumentos de contexto disponibles, y lo componen dos clases de cosas: los parámetros de contexto de las declaraciones que envuelven la llamada, y los receptores implícitos que haya en ese punto, incluidos el receptor de despacho, el de extensión y los que introducen funciones como with o run.

fun main() {
    val log: Logger = ConsolaLogger()

    // procesar(pedido)          // error de compilacion: no hay contexto

    with(log) {
        procesar(pedido)          // el receptor de with sirve de argumento de contexto
    }
}

context(log: Logger)
fun flujoCompleto(pedidos: List<Pedido>) =
    pedidos.map { procesar(it) }  // el contexto propio sirve al llamar hacia abajo

Conviene subrayar que la búsqueda es por tipo y solo por tipo: el compilador no mira nombres, no mira anotaciones y no consulta ningún registro. Un valor cuyo tipo sea el requerido o cualquier subtipo suyo es candidato, y un valor de otro tipo no lo es aunque se llame igual que el parámetro de contexto. De ahí se sigue la primera regla práctica de todo el nivel, que la última lección convertirá en criterio de diseño: el tipo de un contexto tiene que ser específico y propio, porque es la única llave que abre la puerta.

La segunda forma es la interesante y la que define el estilo: una función que ya declara el contexto se lo pasa gratis a todo lo que llame dentro, sin escribir nada. El arrastre de la lección anterior desaparece de las firmas intermedias, pero no desaparece de la comprobación: cada eslabón sigue declarando lo que exige, y el compilador sigue verificando la cadena entera.

flowchart TD
A[Sitio de llamada] --> B{Hay un valor del tipo requerido}
B -- Parametro de contexto en un ambito envolvente --> C[Se pasa ese]
B -- Receptor implicito de with o de la clase --> D[Se pasa ese]
B -- No hay ninguno --> E[Error NO CONTEXT ARGUMENT]
B -- Hay dos en el mismo ambito --> F[Error AMBIGUOUS CONTEXT ARGUMENT]

Los dos errores del diagrama son los que vas a ver de verdad y conviene reconocerlos por su nombre. El primero, NO_CONTEXT_ARGUMENT, aparece cuando en el punto de llamada no hay ningún valor del tipo pedido; el mensaje señala la llamada y menciona el parámetro de contexto que quedó sin satisfacer. Es un error de compilación puro y ese es todo el objetivo del mecanismo: la dependencia que antes se descubría en ejecución ahora se descubre al compilar. El segundo, AMBIGUOUS_CONTEXT_ARGUMENT, aparece cuando hay más de un candidato aplicable en el mismo nivel de ámbito y el compilador se niega a adivinar; la lección siguiente estudia el orden de búsqueda que decide cuándo dos candidatos están o no en el mismo nivel.

Propiedades, sobrescritura y límites

Una propiedad también puede declarar contexto, y el caso natural es el de la propiedad calculada que depende de un servicio ambiental, como una representación formateada que necesita conocer la localización.

context(fmt: Formateador)
val Pedido.totalLegible: String
    get() = fmt.moneda(total)

Aquí hay una restricción que conviene grabar: una propiedad con parámetros de contexto no puede tener campo de respaldo, de modo que tiene que declarar un get explícito y no admite inicializador ni delegación por lazy. La razón es de aritmética elemental: un campo existe una vez por instancia, mientras que el valor de una propiedad contextual depende de qué contexto haya en cada lectura, así que puede dar resultados distintos en dos lecturas de la misma instancia. Guardar eso en un campo no tendría ningún sentido.

La misma lógica explica una restricción vecina que sorprende menos cuando se ve así: una propiedad contextual tampoco admite delegación, porque un delegado se instala una vez y la propiedad tendría que consultarlo con un contexto que cambia en cada lectura. En ambos casos el compilador no está prohibiendo algo útil, sino impidiendo escribir una contradicción.

context(fmt: Formateador)
val Pedido.totalLegible: String get() = fmt.moneda(total)   // correcto

// context(fmt: Formateador)
// val Pedido.cacheado: String by lazy { fmt.moneda(total) } // no compila

Las demás restricciones dibujan con bastante nitidez el alcance del mecanismo. Los parámetros de contexto se declaran sobre elementos invocables, es decir, funciones y propiedades, y no sobre clases ni sobre constructores: una clase que necesita un servicio para vivir lo recibe por constructor, como siempre, porque su dependencia no es de ámbito sino de identidad. Al sobrescribir un miembro que declara contextos, la implementación tiene que declarar los mismos tipos en el mismo orden, aunque puede elegir otros nombres, exactamente igual que ocurre con los nombres de los parámetros de valor.