typescript --strictNullChecks vs. la comprobación de nulos de flow
Si ejecuto "typescript --strictNullChecks" sobre el código siguiente, no obtengo errores. Si ejecuto flow sobre él, me da un error sobre la incompatibilidad de tipos de null frente a number. ¿Por qué TypeScript no da también un error en esto? ¿Es eso una función o un problema que vale la pena registrar?
// @flow
var f = function f( x ) {
var y = x * 2;
}
f(null);
Respuesta #1
TypeScript no realiza análisis del sitio de llamada.
TypeScript ve esto, lo cual está bien:
var f = function f( x: any ) {
var y = x * 2;
}
f(null);
Flow ve:
var f = function f( x: ??? ) {
var y = x * 2;
}
f(null);
donde ??? se determina observando las llamadas en el archivo actual. En este caso, x tiene el tipo simple null y está en error.
¿Por qué TypeScript no infiere los tipos a partir de los sitios de llamada? En general, los mensajes de error que una computadora puede generar al hacer esto son vagos: lo que a menudo se ve en Flow es que pasas el tipo de argumento incorrecto a una función, obtienes un error en el cuerpo de la función correctamente implementada (o en una función posterior), y luego tienes que trabajar hacia atrás para ver de dónde provino el argumento problemático. A veces esto simplemente no está claro: si la mitad de tu código escribiera fileName y la otra mitad escribiera filename y pasas una mezcla de esos objetos, ¿quién puede decir quién está equivocado? La respuesta de TypeScript es "pon una anotación de tipo que explique lo que pretendías" para que puedas obtener errores de alta especificidad.
Y debido a que este análisis es más costoso, no es adecuado para el análisis de programas completos. Así que Flow solo realiza esta inferencia por archivo, lo que significa que generalmente deseas tener anotaciones de tipo en cada función en el "límite" de un archivo y en los archivos con los que interactúa. Y como esos límites son donde se encuentran la mayoría de los errores, no siempre te aporta tanto como podría parecer a primera vista.
