Здравствуйте, samius, Вы писали:
S>Де-факто в мейнстриме мы и этого не имеем. Тупл-то вообразить можем, а проверить идентичность — нет.
Просто мейнстрим, в отличие от академики, требует реальных решений для реальных проблем.
Поэтому встраивают поддержку паттернов, отличных от "отправить один объект в качестве сообщения другому объекту".
Ну, вот как с теми же енумами в Джаве.
С точки зрения теории кристалла, енум можно эмулировать при помощи класса, у которого есть финитное количество экземпляров. Экземпляры созданы до начала работы пользовательского кода и никогда не умирают.
Для того, чтобы этот класс изобразить, нужно много "подпорок" и надстроек над исходной минимальной ООП-моделью. Нужна поддержка статических методов; нужна поддержка запечатанных классов; нужна поддержка приватных конструкторов.

И даже когда всё это есть, желателен синтаксический сахар, потому что руками описывать все эти public static readonly Color.Red = new object(); — занудство.

После этого при использовании можно опираться на ссылочную эквивалентность.

Понятно, что всё это — изоморфно подмножеству натуральных чисел, поэтому в некоторых языках, которые не стесняются мультипарадигменности, енумы реализуются не как сахар над ООП, а по-настоящему.

Примерно то же самое мы имеем по отношению к абстрактной "передаче сообщения" vs. "вызов метода".
В абстрактной академике биндинг выполняется полностью принимающей стороной, а в качестве сообщения может выступать всё, что угодно.
В конкретном мейнстриме имеются методы, сигнатуры, сложные правила совместимости, статический биндинг и прочее. Потому, что надо работать, а не доказывать достаточность минимального базиса.