oke

1. Open world assumption. Её семантика проверить то что знакомо и не трогать то что не знакомо.
2. Можно применить к другим задачам помимо валидации. Из популярного генерация тестов и примеров.
3. Может использоваться как язык запросов, регулярка.
4. Расширяема произвольными предикатами.

ORM? OMG!

Ковыряю щас один продукт от IBM. Вроде все достойно. Более-менее правильный ООП. А потом бабах: в новой версии попытались ввести chained parsers, но не смогли…
Т.е. в классе Parser завели поле chainedParser, а как потом это юзать не смогли придумать.
Это я к чему?
Не осилили они композируемость.

в кложе ООП вроде нет от слова совсем. что за продукт?

А чем рекорды не ооп?

М, а чер ооп?

Инкапсуляции? Скрытый стейт?

Рекорды сами по себе инкапсуляции, а скрытый стейт даже нигде не упоминается как что-то нужное

Да, не. Это не про кложу. Это скорее про композируемость в ООП. Слёзы и боль.
Продукт — IBM SDI.

Они попытались сделать что-то типа «цепочки ответственности» или как оно там называется. И не стали пока полностью впиливать.  Только поле в классе оставили и где-то в доках пометили: future implementation.

А мне щас надо!

рекорд не обладает поведением. из названия - набор каких-то данных (кортеж с именами)

А методы в рекорды можно добавить?

Можно, через протоколы

поля рекорда имутабельны же

Если сделать их атомами, то мутабельные

в этом и состоит большая ошибка неправильного понимания ООП. в хорошом объекте данные не торчат наружу. только методы.

Это уже натягивание совы на глобус

Я тоже так могу: хорошее ооп это когда поля иммутабельны, а наследования нет

простой пример распознавание текста с экрана.  допустим объект распознает текст и сохраняет данные в виде списка кортежей (слово, координаты). если его выставить наружу то сразу же в полезут баги. если же оно приватное, то разработчик компонента контролирует стэйт и объектом легко и удобно пользоваться. при наличии интерфейса мы даже забываем о реализации(используя инверсию зависимостей). но да ооп сложней фп. фп это кирпичи, ооп это клей.