Hmm ... Definisi itu terlihat sangat mirip dengan beberapa sampel haskell yang pernah saya lihat sejak lama.
{-# 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]
Ketika konstruktor Xditerapkan ∀ sebenarnya menjadi ∃. Perhatikan bahwa ketika Anda mengeluarkan valueAnda tidak tahu jenis dan memiliki set operasi kosong di atasnya. Tapi karena viewValueagak koheren dengan valueitu dapat diterapkan padanya.
Saya kira perbedaan utama dari Java interfaceAnda diusulkan adalah kenyataan bahwa Anda harus mengetahui jenis perantara untuk hasil kelulusan dari op₁ke op₂. Yaitu sistem yang tepat untuk tipe eksistensial harus memilih tipe yang tepat yang dijamin ada kondisinya. Yaitu Anda harus bisa menulis fungsi dengan jenis: ∀X. X→(X→boolean)→T. Dalam contoh sebelumnya fungsi tersebut adalah Xkonstruktor yang digunakan di X 3 show( showadalah fungsi yang mengambil argumen dari semua jenis yang mengimplementasikan Showdan mengembalikan String)
Diperbarui: Saya baru saja membaca kembali pertanyaan Anda dan saya pikir saya punya konstruksi yang tepat untuk 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₂()) ...
Anda benar tentang menyebutkan this- itu sebenarnya op₁ Anda.
Jadi saya kira saya mengerti sekarang bahwa bahasa OOP klasik (Java, C #, C ++ dll) selalu menerapkan tipe eksistensial dengan nilai tunggal thisdan fungsi di atasnya disebut "metode" yang secara implisit disebut dengan nilai itu :)
PS Maaf, saya tidak terlalu terbiasa dengan Java, tapi saya harap Anda punya idenya.