Làm thế nào để các loại tồn tại khác với giao diện?

Cho kiểu tồn tại

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

và giao diện Java chung này:

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

Sự khác biệt cơ bản giữa loại tồn tại và giao diện Java là gì?

Rõ ràng có sự khác biệt về cú pháp và hướng đối tượng của Java (cũng bao gồm các chi tiết như các thistham số ẩn, v.v.). Tôi không quan tâm nhiều đến những điều này như về sự khác biệt về khái niệm và ngữ nghĩa - mặc dù nếu ai đó muốn làm sáng tỏ một số điểm tốt hơn (chẳng hạn như sự khác biệt về công chứng giữa Tso với T<X>), điều đó cũng sẽ được đánh giá cao.

Hmm ... Định nghĩa đó trông rất giống với một số mẫu haskell mà tôi đã thấy từ lâu.

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

Khi constructor Xđược áp dụng ∀ thực sự trở thành ∃. Lưu ý rằng khi bạn lấy ra, valuebạn không biết loại và có bộ hoạt động trống trên nó. Nhưng vì viewValuenó phù hợp với valuenó có thể được áp dụng cho nó.

Tôi đoán sự khác biệt chính của Java interfacemà bạn đề xuất là thực tế là bạn phải biết loại trung gian để truyền kết quả op₁cho op₂. Tức là hệ thống thích hợp cho loại tồn tại nên chọn đúng loại được đảm bảo tồn tại theo điều kiện. Tức là bạn sẽ có thể viết hàm với loại : ∀X. X→(X→boolean)→T. Trong mẫu trước, hàm như vậy là hàm Xtạo được sử dụng trong X 3 show( showlà hàm lấy đối số của bất kỳ kiểu nào thực hiện Showvà trả về String)

Đã cập nhật: Tôi vừa đọc lại câu hỏi của bạn và tôi nghĩ rằng tôi đã xây dựng đúng cho 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₂()) ...

Bạn đã đúng khi đề cập this- thực sự đó là op của bạn.

Vì vậy, tôi đoán bây giờ tôi đã hiểu rằng các ngôn ngữ OOP cổ điển (Java, C #, C ++, v.v.) luôn thực hiện kiểu tồn tại với một giá trị duy nhất thisvà một hàm trên nó được gọi là "phương thức" được gọi ngầm với giá trị đó :)

PS Xin lỗi, tôi không quen thuộc lắm với Java, nhưng tôi hy vọng bạn đã có ý tưởng.

Sự khác biệt duy nhất là giao diện Java thực sự có ý nghĩa gì đó với trình biên dịch Java.

Loại tồn tại là định nghĩa chính thức của một loại, không cụ thể đối với bất kỳ ngôn ngữ nào. Các nhà khoa học máy tính sử dụng loại định nghĩa này để chứng minh những điều về loại và về ngôn ngữ thực hiện nó. Giao diện Java là một trong những triển khai của Java thuộc loại được xác định chính thức.

Hai loại trình bày rất khác nhau. Định nghĩa giao diện bạn đã viết là một loại phổ quát (nói chung về Java nằm trong danh mục này).

Một kiểu tồn tại ẩn một loại trong quá trình thực hiện của nó từ người tiêu dùng. Theo trực giác, để X tồn tại trong T, danh tính của X có thể được biết đến từ bất kỳ người tiêu dùng nào; tất cả những gì nên biết là tập hợp các hoạt động được cung cấp theo định nghĩa. Tồn tại một loại T cho một số loại X.

Ngược lại, một loại phổ quát xác định các hoạt động áp dụng cho tất cả các loại, từ đó người tiêu dùng có thể tự do lựa chọn. Kiểu giao diện T chính xác là như vậy. X được người tiêu dùng khởi tạo, những người sẽ biết chính xác loại X là gì. Tồn tại một loại T cho mọi loại X trong vũ trụ.

Các tồn tại không thực sự hiện diện trong Java như là một cấu trúc ngôn ngữ, ngoại trừ trong trường hợp giới hạn của các ký tự đại diện ( List<?>). Nhưng vâng, chúng có thể được mô phỏng với các giao diện. Vấn đề sau đó trở nên nhiều hơn về thiết kế.

Như ony đã chỉ ra, trong một thiết lập hướng đối tượng, các tồn tại trở nên khó thực hiện bởi vì cách bạn thường mã hóa thông tin loại của X (những gì bạn có thể làm với nó) là có các hàm thành viên trong loại giao diện mà X thực hiện. Nói tóm lại, các giao diện có thể mua một số khả năng trừu tượng hóa, nhưng yêu cầu loại bỏ sự tồn tại ở một mức độ nào đó.