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

S>>Вот вам ООП подход.

SP>Замечу, что здесь нет изменяемого состояния.
Совершенно верно. Я об этом и говорю — без изменяемого состояния ООП от ФП практически неотличимо. "Интерфейсы" без мутабельности прекрасно реализуются на ФП.

S>>Вот как раз тут видно, почему ООП без изменяемого состояния — "не ООП".
SP>Мне видно противоречие.
Где именно?
SP>На первый взгляд в ООП инкапсуляция явно противоречит иммутабельности. Но на самом деле это чисто технический момент. Следующий код с изменяемым состоянием

SP>

SP>class MyObject {
SP>    int _v;
SP>    public: void setField(int v) { _v = v; }
SP>};
SP>

SP>легко преобразуется в иммутабельный

SP>

SP>class MyObject {
SP>    int _v;
SP>    public: MyObject setField(int v)&& { this->_v = v; return *this; }
SP>}
SP>

Простите, это на каком языке?
SP>да, такой код не очень идиоматичен. Но чисто технически он иммутабельность убирает.
Если я правильно понимаю, вы просто переписали мой пример кода с "иммутабельной мутабельностью" на другой язык. При этом, как мне кажется, вы допустили ошибку — вы же this меняете, нет тут никакой иммутабельности.
Для проверки попробуйте добавить const к определению int _v.

SP>В языках типа С# и Java конечно такое тяжело (нет move семантики),
Не очень понятно, при чём тут move семантика.
SP>но начиная с С++ и Rust так извращаться уже можно. В данном случае ограничения языков не должны вводить в заблуждение относительно ограниченности ООП. В ООП стиле можно писать даже иммутабельно
Такое "ООП" плохо не тем, что оно иммутабельное, а тем, что это — не ООП.
Собственно, как и следовало ожидать, оно с той же громоздкостью выражается на ФП. Потому что — см. предыдущий пункт: в отстутствие изменяемого состояния, "объект" — это просто пачка функций, объединённых общим замыканием.