Cuando pensamos en un lenguaje de programación, solemos imaginar su sintaxis, su compilador o su sistema de tipos.
Sin embargo, existe otro componente igual de importante: la biblioteca estándar.
De poco sirve tener una sintaxis elegante si los tipos fundamentales del lenguaje no forman un modelo coherente.
En este artículo comenzaremos a diseñar tres de los tipos más importantes de MateScript:
- Object
- Null
- Optional
Los tres estarán profundamente relacionados.
En el artículo anterior llegamos a una conclusión interesante.
Queríamos que el desarrollador pudiera escribir:
let name: String?;
Pero no queríamos que el operador ? fuera una característica mágica del compilador.
Por eso decidimos definirlo como un alias de tipos.
T?
es equivalente a:
Optional<T>
Y Optional<T> se implementa utilizando un Union Type.
class Optional<T> {
value: T | Null;
}
Ahora la pregunta cambia.
¿Cómo deben comportarse Optional y Null?
Como MateScript se ejecutará sobre la JVM, tiene sentido adoptar un modelo de objetos similar al de Java.
Todos los objetos heredarán de una clase base.
class Object {
equals(other: Object): Boolean
hashCode(): Int
toString(): String
}
Esto significa que cualquier objeto del lenguaje compartirá el mismo comportamiento básico.
Por ejemplo:
person.toString()
list.hashCode()
optional.equals(other)
No existen excepciones.
Todo es un objeto.
MateScript intenta reducir la cantidad de código repetitivo.
Por eso no será necesario escribir modificadores como:
public
private
protected
La regla será mucho más simple.
Los atributos serán privados por defecto.
Los métodos serán públicos por defecto.
Por ejemplo:
class Person {
name: String
age: Int
greet() {
print("Hello!")
}
}
Es una sintaxis muy cercana a TypeScript, pero manteniendo un modelo de objetos inspirado en Java.
En muchos lenguajes, null es un valor especial incorporado por el compilador.
En MateScript queremos seguir un enfoque diferente.
Null será un objeto singleton.
object Null {
toString(): String
equals(other: Object): Boolean
hashCode(): Int
}
Existirá una única instancia.
Como cualquier otro objeto del lenguaje.
No será un valor mágico.
No requerirá reglas especiales.
Cuando empezamos a diseñar Optional, apareció una idea interesante.
Supongamos el siguiente código.
let name: String? = ...
let upper =
name.map(x => x.toUpperCase());
¿Qué ocurre si name no contiene ningún valor?
Una posibilidad sería lanzar una excepción.
Otra sería devolver un nuevo Optional.
Pero existe una alternativa mucho más elegante.
Que el propio objeto Null implemente el mismo comportamiento.
Por ejemplo:
Null.map(...)
simplemente devolvería:
Null
Lo mismo ocurre con:
Null.flatMap(...)
Null.filter(...)
Todas estas operaciones simplemente devolverían nuevamente Null.
Esto permite que el código continúe fluyendo de forma natural sin necesidad de realizar comprobaciones constantes.
¿Entonces map pertenece a Object?
Podría parecer una buena idea.
Después de todo, todos los objetos podrían responder al método map().
Sin embargo, rápidamente aparecen situaciones extrañas.
5.map(...)
person.map(...)
car.map(...)
¿Qué significa transformar un número mediante map()?
¿O una persona?
La realidad es que map() no representa una operación común a todos los objetos.
Representa una operación sobre estructuras que contienen un valor.
En lugar de agregar map() a Object, resulta más razonable definir una interfaz específica.
Conceptualmente podría verse así:
interface Functor<T> {
map<R>(
mapper: (T) -> R
): Functor<R>;
}
Esta idea proviene de la programación funcional y aparece en lenguajes como Haskell, Scala y muchos otros.
No es necesario conocer teoría de categorías para utilizarla.
La idea es muy sencilla.
Un Functor es cualquier estructura capaz de transformar el valor que contiene sin perder su estructura.
Ahora Optional puede implementar esa interfaz.
class Optional<T>
implements Functor<T> {
value: T | Null;
}
Cuando existe un valor, map() aplica la función recibida.
Cuando el valor es Null, simplemente devuelve Null.
Desde el punto de vista del desarrollador, el código siempre se escribe de la misma manera.
name
.map(...)
.map(...)
.map(...)
Sin preguntar constantemente si existe un valor.
Lo interesante es que nunca planeé incorporar conceptos de programación funcional.
Simplemente estaba buscando una forma elegante de implementar Optional.
Sin embargo, al avanzar en el diseño comenzaron a aparecer naturalmente ideas como:
- objetos singleton;
- Union Types;
- Functors.
Y eso es una de las cosas más fascinantes de diseñar un lenguaje.
Las buenas abstracciones suelen aparecer como consecuencia de resolver problemas reales, no como un objetivo en sí mismo.
En este punto, MateScript comienza a tener una identidad propia.
- Todos los objetos heredan de Object.
- Null deja de ser un valor mágico para convertirse en un objeto singleton.
- Optional<T> representa explícitamente la posibilidad de ausencia mediante T | Null.
- Las operaciones de transformación se modelan mediante interfaces específicas, manteniendo la clase Object pequeña y coherente.
