Чим екзистенціальні типи відрізняються від інтерфейсів?

З огляду на екзистенційний тип

T = ∃X.{op₁:X, op₂:X→boolean}

і цей загальний інтерфейс Java:

interface T<X> {
    X op₁();
    boolean op₂(X something);
}

Які принципові відмінності між екзистенціальним типом та інтерфейсом Java?

Очевидно, є синтаксичні відмінності та об’єктна орієнтація Java (яка також включає деталі, такі як приховані thisпараметри тощо). Я не стільки зацікавлений в них , як в концептуальних і смислових розходженнях - хоча , якщо хто - то хотіли б, щоб пролити світло на деякі моменти більш дрібних (наприклад, нотаціонная різниця між TVS. T<X>), який був би оцінений теж.

Гм ... Це визначення дуже схоже на зразок haskell, який я бачив давно.

{-# 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]

При застосуванні конструктора X∀ фактично стає ∃. Зауважте, що виймаючи, valueви не знаєте тип і маєте порожній набір операцій над ним. Але оскільки вона viewValueє якоюсь узгодженою з valueним, можна застосувати до нього.

Я думаю, що головна відмінність Java, interfaceяку ви запропонували, полягає в тому, що ви повинні знати проміжний тип для проходження результату op₁до op₂. Тобто належна система для екзистенціального типу повинна вибрати правильний тип, який гарантовано існує за умови. Тобто ви повинні бути в змозі написати функцію з типом: ∀X. X→(X→boolean)→T. У попередньому зразку така функція Xвикористовується конструктором X 3 show( showце функція, яка бере аргумент будь-якого типу, що реалізує Showта повертає String)

Оновлено: Я просто перечитав ваше запитання і, думаю, у мене належна конструкція для 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₂()) ...

Ви маєте рацію згадати this- це насправді ваша оп₁.

Отже, я думаю, я зрозумів, що класичні мови OOP (Java, C #, C ++ тощо) завжди реалізують екзистенціальний тип з одним значенням thisі функціями над ним, що називаються "методами", які неявно називаються цим значенням :)

PS Вибачте, я не дуже знайомий з Java, але сподіваюся, що у вас виникла ідея.

Єдина відмінність полягає в тому, що інтерфейс Java насправді щось означає для компілятора Java.

Екзистенціальний тип - це формальне визначення типу, неспецифічне для будь-якої мови. Комп'ютерні вчені використовують таке визначення, щоб довести речі про тип та про мови, які його застосовують. Інтерфейс Java - одна з реалізацій Java формально визначеного типу.

2 представлені типи сильно відрізняються один від одного. Написане вами визначення інтерфейсу є універсальним типом (загальна Java-дженерики взагалі потрапляє до цієї категорії).

Екзистенційний тип приховує тип у межах своєї реалізації від споживача. Інтуїтивно, щоб X був екзистенціальним в T, особистість X не може бути відома жодному споживачеві; все, що слід знати, - це набір операцій, наданий при визначенні. Для одного типу X існує один тип T.

Навпаки, універсальний тип визначає операції, застосовні до всіх типів, з яких споживач вільний у виборі. Тип інтерфейсу T саме такий. X призначається споживачем, який точно знатиме, що таке тип X. Існує тип T для кожного типу X у Всесвіті.

Екзистенціалі фактично не наявні в Java як мовна конструкція, за винятком обмеженого підстановки ( List<?>). Але так, їх можна імітувати за допомогою інтерфейсів. Проблема потім стає більше дизайну.

Як зазначав Оні, в об'єктно-орієнтованій обстановці екзистенціали стають складними для реалізації, оскільки спосіб, як правило, кодувати інформацію про тип X (що ви можете зробити з ним), - це мати функції учасників у типі інтерфейсу, який реалізує X. Коротше кажучи, інтерфейси можуть купувати певні можливості абстракції, але вимагають усунення екзистенціалу певною мірою.