Resolución estática: el tipo escrito manda

Si una función de extensión se compila como una función estática cuyo primer parámetro es el receptor, entonces la pregunta interesante deja de ser qué hace y pasa a ser cuál se llama. En un método normal la respuesta la da el objeto: la máquina virtual consulta la tabla de métodos de la clase real y ejecuta la implementación que corresponde, sin importar cómo hayas anotado la variable. En una extensión la respuesta la da el compilador antes de que exista ningún objeto, mirando únicamente el tipo que escribiste. Son dos mundos con reglas incompatibles conviviendo bajo la misma sintaxis de punto, y el precio de confundirlos es un programa que ejecuta código correcto sobre el objeto equivocado sin emitir ni un aviso.

El tipo declarado decide, y decide antes de ejecutar

El caso canónico cabe en diez líneas y conviene sabérselo de memoria, porque es el que aparece disfrazado en producción.

open class Forma
class Circulo : Forma()

fun Forma.nombre() = "forma"
fun Circulo.nombre() = "circulo"

fun main() {
    val f: Forma = Circulo()
    println(f.nombre())   // forma
}

El objeto es un Circulo. La salida es forma. No hay ningún misterio en cuanto se recuerda la traducción del nivel anterior: la llamada se compiló como nombre(f), y en ese punto lo único que el compilador sabe de f es que está declarada como Forma. La sobrecarga se resolvió por el tipo estático del argumento, exactamente igual que se resolvería la elección entre dos funciones libres nombre(f: Forma) y nombre(c: Circulo) de Java. La máquina virtual nunca llega a participar en la decisión: cuando el programa arranca, la elección ya está grabada en el bytecode.

flowchart TB
llamada[expresion punto nombre] --> q{es un miembro del tipo}
q -->|si| miembro[despacho virtual por la clase real en ejecucion]
q -->|no| ext[busqueda de extensiones importadas en el ambito]
ext --> sel[se elige por el tipo estatico del receptor]
sel --> fija[la eleccion queda fijada en compilacion]

Nada de esto es un fallo del lenguaje: es lo mismo que ocurre con la sobrecarga de funciones en cualquier lenguaje estático. El problema es que la sintaxis de punto sugiere despacho dinámico, y la intuición de quien lee el código viene entrenada por los métodos.

La contraprueba lo deja claro. Basta con quitar la anotación de tipo para que la salida cambie sin haber tocado ni el objeto ni las extensiones:

val a: Forma = Circulo()
val b = Circulo()          // tipo inferido: Circulo

println(a.nombre())        // forma
println(b.nombre())        // circulo

Dos variables que apuntan a instancias equivalentes producen resultados distintos porque el compilador dedujo tipos estáticos distintos. Es exactamente el mismo objeto para la máquina virtual y dos llamadas diferentes en el bytecode.

El miembro siempre gana

La segunda regla es más simple de enunciar y más peligrosa a largo plazo: si el tipo tiene un miembro con la misma firma, el miembro se llama y la extensión queda muerta.

class Caja {
    fun imprimir() = println("miembro")
}

fun Caja.imprimir() = println("extension")

fun main() {
    Caja().imprimir()   // miembro
}

Kotlin avisa aquí con la advertencia de que la extensión está siendo ocultada por un miembro, pero es una advertencia y no un error, y sobre todo solo se emite cuando ambos son visibles en la misma compilación. La precedencia no admite excepciones ni se puede invertir: no existe forma de forzar la llamada a la extensión con la sintaxis de punto, y para invocarla hay que escribirla como lo que realmente es, una función con un argumento.

import dominio.caja.imprimir as imprimirExt

fun main() {
    imprimirExt(Caja())   // extension, llamada como funcion
}

Ahora bien, la regla habla de firmas, no de nombres. Una extensión con parámetros distintos no queda oculta: entra en el juego normal de la sobrecarga junto a los miembros, con la particularidad de que los miembros se consideran primero y solo si ninguno es aplicable se buscan las extensiones.

class Caja {
    fun imprimir() = println("miembro sin argumentos")
}

fun Caja.imprimir(prefijo: String) = println("$prefijo extension")

fun main() {
    Caja().imprimir()          // miembro sin argumentos
    Caja().imprimir("hola")    // hola extension
}

La factura la paga el futuro

Que el miembro gane significa que cualquier extensión que escribas sobre un tipo ajeno es un contrato que la otra parte puede romper sin saberlo. El día en que la librería publique una versión con un método de la misma firma, tu extensión dejará de ejecutarse en todas las llamadas del proyecto. Nada dejará de compilar: el código sigue siendo válido, la sintaxis es idéntica y el comportamiento cambia por debajo.

El escenario completo, en orden: