TypeScript

TypeScript conserva el modelo de funciones como valores de JavaScript y permite describir sus parámetros y resultado con tipos estáticos.

Referencia Kotlin: Declarar una operación reutilizable y recibir otra operación como valor.

Mecanismo

Funciones declaradas o expresiones flecha con un tipo de función explícito.

Idea conservada

La transformación se recibe como valor y se invoca dos veces sobre el mismo argumento; quien la declara no necesita conocer applyTwice.

Riesgo de diseño

Usar el tipo global Function, que pierde la firma concreta y devuelve any al invocar.

Recomendación

Escribe una firma de función explícita en las fronteras de una API.

Convención del curso

En este curso, anota parámetros y retorno en las funciones exportadas; deja que el contexto infiera los tipos locales.

Mecanismo del lenguaje

Funciones declaradas y expresiones flecha con un tipo de función.

Diferencias relevantes

• Las funciones se emiten como JavaScript y su comprobación de tipos ocurre antes de ejecutar.
• El tipo (number) => number no comprueba por sí mismo efectos ni pureza.

La firma de la transformación se expresa como un tipo de función.

fun applyTwice(
    value: Int,
    transform: (Int) -> Int,
): Int = transform(transform(value))

val result = applyTwice(3) { it + 1 } // 5

function applyTwice(value: number, transform: (value: number) => number): number {
    return transform(transform(value));
}

const result = applyTwice(3, (number) => number + 1); // 5

Otra forma de recibir comportamiento: un predicado para filtrar un arreglo.

const keep = (xs: number[], p: (x: number) => boolean) => xs.filter(p);

Fuentes

• TypeScript Handbook: More on Functions
• Kotlin: funciones de orden superior y lambdas

El rest parameter recoge los argumentos en un arreglo real dentro de la función, así que values admite directamente los métodos de Array sin conversión adicional. Para pasar un arreglo ya existente hay que expandirlo con spread (...values) en el sitio de la llamada; TypeScript rechaza pasar el arreglo directamente porque no coincide con la firma variádica.

Referencia Kotlin: Una función recibe vararg values: Int.

Mecanismo

rest parameter ...values: number[]

Riesgo de diseño

Pasar un arreglo existente directamente (seeds(values)) esperando que se expanda solo, en vez de usar seeds(...values).

Recomendación

Declara el rest parameter al final de la firma y expande explícitamente cualquier arreglo existente con spread al llamar.

Convención del curso

El rest parameter siempre es el último parámetro de la firma.

Mecanismo del lenguaje

Rest parameter tipado como number[].

Diferencias relevantes

• El rest parameter debe ser el último parámetro de la firma.
• Igual que un vararg de Kotlin, un arreglo existente debe expandirse explícitamente con spread para pasarlo; ninguno de los dos lenguajes lo acepta como un solo argumento.

Un rest parameter recoge los argumentos en un arreglo real.

export function seeds(...values: number[]): readonly number[] {
    return values;
}

Fuentes

• TypeScript Handbook: More on Functions — Rest Parameters

La compatibilidad de TypeScript es estructural: cualquier valor cuya forma incluya los miembros declarados conforma la interfaz, sin necesidad de una declaración implements explícita. Una interfaz tampoco vuelve exacto un tipo de objeto: un valor con miembros adicionales sigue conformando, salvo en un caso concreto.

Referencia Kotlin: Una interfaz declara comportamiento sin fijar una representación.

Mecanismo

interfaz estructural

Riesgo de diseño

Suponer que una clase o un objeto necesita declarar implements Score para conformar la interfaz, o que la comprobación de propiedades excedentes se aplica a cualquier asignación y no solo a literales frescos.

Recomendación

Declara solo los miembros que el contrato necesita y confía en la conformidad estructural; no agregues implements por costumbre.

Convención del curso

No declares implements Score; la conformidad estructural ya lo garantiza.

Mecanismo del lenguaje

Interfaz estructural con comprobación de propiedades excedentes en literales frescos.

Diferencias relevantes

• Un objeto literal fresco asignado directamente donde se espera Score sí se revisa con comprobación de propiedades excedentes, y un miembro inesperado lo rechaza.
• El mismo objeto, guardado primero en una variable, deja de ser un literal fresco y la asignación se acepta estructuralmente.

Cualquier forma con un value numérico conforma Score, sin declarar implements.

export interface Score {
    readonly value: number;
}

export function readScore(score: Score): number {
    return score.value;
}

Fuentes

• TypeScript Handbook: Type Compatibility
• TypeScript Handbook: Object Types — Excess Property Checks