Jerf define los colores de función como dependencias de cambio
El bloguero Jerf propone un criterio técnico para distinguir parámetros normales de colores, basándose en cómo se propagan las modificaciones en la pila de llamadas.
Jeremy Ashkenas (conocido en el mundo del desarrollo como Jerf) ha publicado un artículo en su blog personal donde ataca la popular idea de que los argumentos de función son, en esencia, "colores". La discusión, recurrente en la comunidad de programación desde la viralización del concepto What color is your function?, suele argumentar que pasar un parámetro como context.Context en Go es funcionalmente idéntico a cambiar la naturaleza de la función (por ejemplo, hacerla asíncrona). Jerf no está de acuerdo. Su tesis es que ambos fenómenos tienen formas de propagación del cambio radicalmente distintas.
La forma del grafo de dependencia
El autor propone que se evalúe si una modificación en una función profunda de la pila de llamadas obliga a reescribir los llamadores.
En el caso de un parámetro normal, el cambio se propaga solo al llamador directo. Si ese llamador encapsula el cambio, la cadena se rompe. Es la base de la programación estructurada: aislar detalles internos. Incluso en el caso extremo de Go, donde se añade un parámetro context.Context, cualquier función puede romper la cadena pasando simplemente context.Background(). El cambio queda contenido localmente.
En el caso de un "color" (como la asincronía en C# o Rust), el cambio no se puede encapsular. Si una función a nivel 4 se vuelve asíncrona, todas las funciones por encima en la pila deben adaptarse obligatoriamente al nuevo comportamiento. No existe una opción neutra o degenerada para "absorber" el cambio sin propagarlo. Esa imposibilidad de romper la cadena es lo que define a un color, no la simple necesidad de pasar un valor.
Jerf destaca que la percepción de que los argumentos son colores surge de una sesgo cognitivo: recordamos fácilmente las veces dolorosas en las que tuvimos que refactorizar toda la pila, pero olvidamos las miles de ocasiones en las que un parámetro cambió sin romper nada. La distinción técnica sigue siendo válida para decidir arquitecturas: los colores cambian el contrato de ejecución; los parámetros solo cambian la firma.
Para quien diseña APIs o evalúa lenguajes, este matiz explica por qué la asincronía es una preocupación de diseño de lenguaje, mientras que los contextos son una convención de librería.
