Здравствуйте, Sinclair, Вы писали:

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

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

Я бы объяснил это проще, тем что ООП натягивали на процедурные языки во времена когда было популярно экономить на вызовах, куда уж говорить о создании объекта на каждый вызов.
Отчасти поэтому мы и имеем кучу работы с сингатурами, сложными правилами совместимости и прочим, вплоть до несовместимости Func/Action в C#. В ФП с более накладным применением аргументов все как-то намного проще.