DT
Но в итоге получается обратное. Потому что ограничений то нет
нет, это значит, что этот нюанс не регламентируется подходом "ООП всеми основными интерпретациями"
Size: a a a
2020 October 07
А
в эрланговом "ООП" "объекты" мутабельные, но это отлично сочетается с иммутабельными данными
Тем более. Но это уже не совсем ООП конечно
AD
И есть привычка писать "под шелезо"
AD
Тем более. Но это уже не совсем ООП конечно
По кею?
DE
Потому что ООП - это мутабельный шаред стейт
Мутабельный. Но не шаред, а локал.
DT
о чем тогда говорит "инкапсуляция" из всем известных столпов ООП?
А
По кею?
Даже по Кею у которого сообщения синхронно посылались
JS
если данные не описывать объектами, то всё хорошо с иммутабельностью
DT
если данные не описывать объектами, то всё хорошо с иммутабельностью
или просто можно учесть, что объекты во всех реализациях компиляторов и интерпретаторов передаются по ссылке
SM
Так для чего иммьютабельность нужна?
DT
Для гарантий
DT
И снижения temporal coupling
А
Мутабельный. Но не шаред, а локал.
С чего это вдруг?
AD
Ещё как шеред
А
вот именно
А
вплоть до расшаривания между потоками
А
нет, это значит, что этот нюанс не регламентируется подходом "ООП всеми основными интерпретациями"
Совсем небольшой нюанс. Но вообще ООП развивается из процедурного программирования, которое императивное и собственно мутации никак не ограничивает. Как и ООП в принципе.
DT
Совсем небольшой нюанс. Но вообще ООП развивается из процедурного программирования, которое императивное и собственно мутации никак не ограничивает. Как и ООП в принципе.
Эмпирическое доказательство можно рассматривать как доказательство, поскольку других нет. Но это не значит что оно верное.
А
иначе это просто демагогия
кхм
А
но вообще ООП - это уже что-то эмпирическое и не особо формальное