Tipos de unión / suma etiquetados en Java

Una forma estándar de codificación de tipos de suma es la codificación Boehm–Berarducci (a menudo referida por el nombre de su primo, Church encoding) que representa un tipo de datos algebraico como su eliminador , es decir, una función que hace coincidencia de patrones:

left :: a -> (a -> r) -> (b -> r) -> r
left x l _ = l x

right :: b -> (a -> r) -> (b -> r) -> r
right x _ r = r x

match :: (a -> r) -> (b -> r) -> ((a -> r) -> (b -> r) -> r) -> r
match l r k = k l r

En Java esto se vería como un visitante:

public interface Either<A, B> {
    <R> R match(Function<A, R> left, Function<B, R> right);
}

public final class Left<A, B> implements Either<A, B> {

    private final A value;

    public Left(A value) {
        this.value = value;
    }

    public <R> R match(Function<A, R> left, Function<B, R> right) {
        return left.apply(value);
    }

}

public final class Right<A, B> implements Either<A, B> {

    private final B value;

    public Right(B value) {
        this.value = value;
    }

    public <R> R match(Function<A, R> left, Function<B, R> right) {
        return right.apply(value);
    }

}

Ejemplo de uso:

Either<Integer, String> result = new Left<Integer, String>(42);
String message = result.match(
  errorCode -> "Error: " + errorCode.toString(),
  successMessage -> successMessage);

Para mayor comodidad, puede crear una fábrica para crear valores Left y Right sin tener que mencionar los parámetros de tipo cada vez; también puede agregar una versión de match que acepte Consumer<A> left, Consumer<B> right en lugar de Function<A, R> left, Function<B, R> right si desea la opción de coincidencia de patrones sin producir un resultado.

Bien, por lo que la solución de herencia es sin duda la más prometedora. Lo que nos gustaría hacer es class Left<L> extends Either<L, ?>, lo que desafortunadamente no podemos hacer debido a las reglas genéricas de Java. Sin embargo, si hacemos las concesiones de que el tipo de Left o Right debe codificar la posibilidad "alternativa", podemos hacer esto.

public class Left<L, R> extends Either<L, R>`

Ahora, nos gustaría poder convertir Left<Integer, A> a Left<Integer, B>, ya que en realidad no usa ese segundo parámetro de tipo. Podemos definir un método para hacer esto conversión interna, codificando así esa libertad en el sistema de tipos.

public <R1> Left<L, R1> phantom() {
  return new Left<L, R1>(contents);
}

Ejemplo completo:

public class EitherTest {

  public abstract static class Either<L, R> {}

  public static class Left<L, R> extends Either<L, R> {

    private L contents;

    public Left(L x) {
      contents = x;
    }

    public <R1> Left<L, R1> phantom() {
      return new Left<L, R1>(contents);
    }

  }

  public static class Right<L, R> extends Either<L, R> {

    private R contents;

    public Right(R x) {
      contents = x;
    }

    public <L1> Right<L1, R> phantom() {
      return new Right<L1, R>(contents);
    }

  }

}

Por supuesto, querrá agregar algunas funciones para acceder realmente al contenido, y para verificar si un valor es Left o Right para que no tenga que rociar instanceof y moldes explícitos en todas partes, pero esto debería ser suficiente para comenzar, como mínimo.

La herencia se puede usar para emular tipos de suma (uniones disjuntas), pero hay algunos problemas con los que debe lidiar:

1. Debe tener cuidado para evitar que otros agreguen nuevos casos a su tipo. Esto es especialmente importante si desea manejar exhaustivamente todos los casos que pueda encontrar. Es posible con una superclase no final y un constructor package-private.
2. La falta de parches de patrones hace que sea bastante difícil consumir un valor de este tipo. Si si desea verificar el compilador para garantizar que ha manejado todos los casos de manera exhaustiva, debe implementar una función de coincidencia usted mismo.
3. Estás forzado a uno de los dos estilos de API, ninguno de los cuales es ideal:
   • Todos los casos implementan una API común, lanzando errores en la API que no admiten por sí mismos. Considere Optional.get(). Idealmente, este método solo estaría disponible en un tipo disjunto cuyo valor se sabe que es some en lugar de none. Pero no hay manera de hacer eso, así que es un miembro de instancia de un tipo general Optional. Lanza NoSuchElementException si lo llamas en un opcional cuyo "caso" es "ninguno".
   • Cada caso tiene una API única que le dice exactamente de qué es capaz, pero eso requiere una comprobación de tipo manual y un cast cada vez que desee llamar a uno de estos métodos específicos de subclase.
4. Cambiar "casos" requiere una nueva asignación de objetos (y añade presión sobre el GC si se hace a menudo).

TL; DR: La programación funcional en Java es no es una experiencia agradable.