Hmm ... Esa definición se parece mucho a una muestra de haskell que he visto hace mucho tiempo.
{-# LANGUAGE ExistentialQuantification #-}
data X = forall a . X { value :: a, viewValue :: a -> String }
instance Show X where show (X { value = x, viewValue = f}) = f x
sample :: [X]
sample = [X 3 show, X "abc" show, X 3.14 show]
Cuando X
se aplica el constructor ∀ en realidad se convierte en ∃. Tenga en cuenta que cuando saca value
no conoce el tipo y tiene un conjunto de operaciones vacío sobre él. Pero dado que viewValue
es un poco coherente con value
él, se le puede aplicar.
Supongo que la principal diferencia de Java interface
que propuso es el hecho de que debe conocer el tipo intermedio para pasar el resultado de op₁
a op₂
. Es decir, el sistema adecuado para el tipo existencial debe seleccionar el tipo correcto que se garantiza que existe por condición. Es decir, que debe ser capaz de escribir con función de tipo: ∀X. X→(X→boolean)→T
. En la muestra anterior, dicha función es un X
constructor utilizado X 3 show
( show
es una función que toma argumentos de cualquier tipo que implementa Show
y devuelve String
)
Actualizado: acabo de volver a leer su pregunta y creo que tengo una construcción adecuada para Java:
interface T {
boolean op₂();
}
...
T x = new T() {
private final int op₁ = ...;
public boolean op₂() { return ((op₁ % 2) == 0); }
};
T y = new T() {
private final char op₁ = ...;
public boolean op₂() { return ('0' <= op₁ && op₁ <= '9'); }
};
if (x.op₂() && y.op₂()) ...
Tienes razón al mencionar this
: en realidad es tu opción.
Así que supongo que entendí ahora que los lenguajes clásicos de OOP (Java, C #, C ++, etc.) siempre implementan el tipo existencial con un solo valor this
y unas funciones sobre él llamadas "métodos" que implícitamente llaman con ese valor :)
PD: Lo siento, no estoy muy familiarizado con Java, pero espero que tengas la idea.