El Row Polymorphism (polimorfismo de filas o de registros) es una característica de los sistemas de tipos que permite definir funciones o tipos que operan sobre registros (records) o estructuras de datos, siempre y cuando estos contengan un subconjunto específico de campos. La clave es que la función no necesita conocer todos los campos del registro, solo aquellos con los que interactúa. Los campos adicionales, si existen, son preservados o ignorados, lo que contrasta con el polimorfismo estructural tradicional donde la coincidencia de tipos requiere una correspondencia exacta de todos los campos.
Este concepto es fundamental en lenguajes de programación funcional con sistemas de tipos avanzados, como OCaml (a través de 'record types' y 'polymorphic variants') y, de manera más explícita, en lenguajes como PureScript y Elm, donde se utiliza para modelar datos de forma flexible. En el ámbito de las bases de datos, aunque no se le llame explícitamente 'Row Polymorphism', la capacidad de las consultas SQL de seleccionar un subconjunto de columnas de una tabla (proyección) o de unificar resultados de tablas con esquemas parcialmente superpuestos (uniones) exhibe una forma análoga de flexibilidad sobre las 'filas' de datos. En sistemas de procesamiento de datos como Apache Spark o Apache Flink, la manipulación de DataFrames o Datasets con esquemas evolutivos también se beneficia de principios similares, donde las operaciones pueden enfocarse en columnas específicas sin requerir un conocimiento exhaustivo de todo el esquema.
Para un arquitecto, el Row Polymorphism es crucial para diseñar sistemas con alta cohesión y bajo acoplamiento. Permite crear APIs y funciones que son más robustas y adaptables a cambios en los esquemas de datos. Facilita la evolución de los modelos de datos sin romper el código existente que solo depende de un subconjunto de campos. Esto reduce la necesidad de refactorizaciones masivas y mejora la mantenibilidad del sistema. Sin embargo, su uso requiere una comprensión clara de los límites del sistema de tipos para evitar errores sutiles. La flexibilidad que ofrece debe sopesarse con la posible pérdida de rigidez que podría ser deseable en contextos donde la validación estricta de esquemas es primordial para la integridad de los datos o la seguridad.