Funciones de extensión: qué son de verdad

La primera vez que escribes fun String.esPalindromo(): Boolean da la sensación de haber abierto una clase sellada de la biblioteca estándar de Java para meterle un método dentro. No ha ocurrido nada de eso. La clase java.lang.String sigue siendo el mismo archivo .class que era antes de que tu proyecto existiera: los mismos miembros, la misma tabla de métodos virtuales, el mismo tamaño de instancia. Lo único que ha pasado es que el compilador de Kotlin ha generado una función estática en otra clase distinta y ha aprendido a traducir la sintaxis de punto para llamarla. Toda la potencia de las extensiones y absolutamente todas sus limitaciones salen de ese hecho único, y entenderlo con precisión es lo que separa usarlas con criterio de sorprenderse cada vez que no hacen lo que parecían prometer.

Lo que escribes y lo que se genera

Una función de extensión declara un tipo receptor delante del nombre. Dentro del cuerpo, this es ese receptor y puede omitirse igual que dentro de un miembro.

// archivo: Texto.kt
package dominio.texto

fun String.esPalindromo(): Boolean {
    val limpio = lowercase().filter { it.isLetterOrDigit() }
    return limpio == limpio.reversed()
}

fun main() {
    println("Anita lava la tina".esPalindromo())  // true
}

El lowercase() sin cualificar del cuerpo es this.lowercase(). La ilusión es completa: se escribe como un método y se autocompleta como un método. Pero el compilador emite algo mucho más humilde, cuya traducción aproximada a Kotlin sería esta:

object TextoKt {
    @JvmStatic
    fun esPalindromo(receptor: String): Boolean {
        val limpio = receptor.lowercase().filter { it.isLetterOrDigit() }
        return limpio == limpio.reversed()
    }
}

Tres consecuencias inmediatas, y las tres importan. La primera: el receptor es un parámetro más, el parámetro cero. La segunda: la función vive en una clase sintética llamada como el archivo con el sufijo Kt, no en String. La tercera: la llamada "texto".esPalindromo() no es una invocación virtual sino una invocación estática que el compilador resuelve mirando el tipo escrito en el código, no el objeto que haya en ejecución.

flowchart LR
src[fun String.esPalindromo] --> comp[compilador de Kotlin]
comp --> cls[clase sintetica TextoKt]
cls --> met[metodo estatico esPalindromo]
met --> p0[parametro 0 igual al receptor]
met --> p1[resto de parametros declarados]

Vista desde Java: aquí se cae el disfraz

Java no conoce las extensiones, así que ve exactamente lo que hay. Y lo que hay es una llamada estática de manual.

import dominio.texto.TextoKt;

public class Main {
    public static void main(String[] args) {
        boolean r = TextoKt.esPalindromo("Anita lava la tina");
    }
}

Ese TextoKt es un nombre generado y, por tanto, parte de tu superficie pública si el proyecto es mixto. Se controla con una anotación de archivo, que debe ir antes de la declaración de paquete:

@file:JvmName("Textos")
package dominio.texto

fun String.esPalindromo(): Boolean = TODO()

Con eso la llamada desde Java pasa a ser Textos.esPalindromo(...). Si varios archivos aportan extensiones al mismo tipo, @JvmMultifileClass permite fundirlos en una sola clase de fachada, que es justo lo que hace la biblioteca estándar para que todo kotlin.text aparezca desde Java bajo StringsKt.

@file:JvmName("Textos")
@file:JvmMultifileClass
package dominio.texto

Merece la pena detenerse en la implicación. Ese nombre generado forma parte de tu compatibilidad binaria desde el primer día en que alguien compile contra él. Cambiar el archivo de sitio, renombrarlo o partirlo en dos altera la clase contenedora y rompe a los clientes de Java aunque ninguna firma de Kotlin haya cambiado. En una librería, por tanto, la organización de los archivos deja de ser una cuestión de gusto y pasa a ser parte del contrato.

Lo que una extensión no puede hacer

Todos los límites siguientes son el mismo límite: una función estática externa no tiene privilegios sobre la clase.

La primera limitación es la que más sorprende y la más sana. Aunque el archivo esté en el mismo paquete y hasta en el mismo módulo que la clase, la extensión queda sujeta a las reglas de visibilidad como cualquier código cliente. Escribir una extensión no es una vía trasera para saltarse la encapsulación de nadie: es una forma de dar nombre a una composición de operaciones que ya podías hacer desde fuera.

class Cuenta(private val saldoCentimos: Long) {
    val saldo: Long get() = saldoCentimos
}

// Error: cannot access saldoCentimos, it is private in Cuenta
fun Cuenta.enEuros(): Double = saldoCentimos / 100.0

// Correcto: solo la API publica
fun Cuenta.enEurosOk(): Double = saldo / 100.0

La segunda limitación tiene una consecuencia que sorprende menos y cuesta más: las extensiones son invisibles para todo lo que trabaje por reflexión. Un serializador, un inyector de dependencias o un motor de plantillas que recorra los métodos declarados de la clase no encontrará ni rastro de ellas, porque objetivamente no forman parte del tipo. La reflexión de Kotlin sí puede alcanzarlas, pero solo a través de la clase contenedora del archivo y como funciones con un parámetro extra, que es lo que realmente son.

Por qué esta forma y no otra