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

V>>>>И прочие GOF-трюки, где иммутабельность может быть св-вом объекта, а может быть адаптером-view.
V>>·>Иммутабельность нельзя через view обеспечить.
V>>Обеспечить-то программным образом можно, ес-но.
·>Нет, нельзя. Ты не можешь сделать иммутабельный view к мутабельному объекту. Вообще никак, это просто бессмысленно. Можно сделать read-only view, но не иммутабельный view.

Заканчивай уже употреблять слова, смысла которых не понимаешь. ))
Если протечек ссылок для мутабельности нет, то автоматом получается иммутабельность.


V>>Нельзя обеспечить, скажем, контроль иммутабельности со стороны компилятора, т.е. нельзя задать гарантии через ср-ва языка.
·>Можно создать иммутабельный объект копируя мутабельные данные

Или литералы-константы, или другие иммутабельные объекты.


·>ну или через передачу владения, собственно всё.

Ес-но.
Об этом и речь, что иммутабельность целиком переезжает на прикладной уровень в джаве, а компилятор умывает руки.
Стоило ли ради этого столько постов трепыхаться? ))


V>>·>Ты тоже что-ли путаешь константность и иммутабельность?
V>>Применительно к данным — это одно и то же.
V>>Применительно к ссылкам/указателям на данные — необходимо уточнять, что имеется ввиду — константность указателя или самих данных.
·>Указатель — это тоже вид данных, не надо мудрствовать.

Именно, как и ссылочная переменная в джаве.
А ты лишь опять сотрясал воздух без понимания определений. ))


V>>Константность можно добавлять неиммутабельным данным по ссылке/указателю, убирать константность нельзя.
V>>То бишь, для любых константных данных их иммутабельность автоматически гарантируется.
·>Иммутабельность гарантируется только тогда, когда к данным нет легального способа получить мутабельный доступ.

Молодец!
Иммутабельность — это иммутабельность!

А константа — это константа!
И для обычных даных это в точности равно иммутабельности.
А для ссылочных данных константность может быть как "приобретаемым позже" свойством, так и неотъемлимым, приобретаемым непосредственно после создания данных (объекта).
Ву а ля!

Я ХЗ где ты тут в 3-х соснах плутаешь. ))


V>>Код, принимающий аргументы по константной ссылке или указателю, может быть одинаков для иммутабельных и неиммутабельных объектов (в части их const-интерфейса) — как прямое следствие возможности добавления к типу модификатора const по указателю/ссылке.
·>Это не достаточное условие.

Этор не условие, дурилки картонные, это св-ва инструментария!

Нет абсолютно никакой потребности обеспечивать иммутабельность типа таком коде, достаточно гарантий, что этот код работает в т.ч. с иммутабельными данными.

Это банальное перепендикулярное разделение данных и кода!

Ладно, тут всё ясно.
Кажется, я понял причину твоих трудностей, что ты тут простыни кода исписал уже, ходишь по кругу. ))

Ты зачем-то рассматривал данные и обрабатывающий его код как нечто неразрывное, верно?

Т.е. умудрился в упор не заметить, что иммутабельные и read-only сценарии существенно пересекаются (read-only сценарии являются строгим подмножеством иммутабельных сценариев).

Так вот, иммутабельность обеспечивается на уровне данных и более никак.
А код пишется как read-only или нет.
И на выходе у нас комбинаторика сценариев, а не сумма их.

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

V>>>>И прочие GOF-трюки, где иммутабельность может быть св-вом объекта, а может быть адаптером-view.
V>>·>Иммутабельность нельзя через view обеспечить.
V>>Обеспечить-то программным образом можно, ес-но.
·>Нет, нельзя. Ты не можешь сделать иммутабельный view к мутабельному объекту. Вообще никак, это просто бессмысленно. Можно сделать read-only view, но не иммутабельный view.

Заканчивай уже употреблять слова, смысла которых не понимаешь. ))
Если протечек ссылок для мутабельности нет, то автоматом получается иммутабельность.


V>>Нельзя обеспечить, скажем, контроль иммутабельности со стороны компилятора, т.е. нельзя задать гарантии через ср-ва языка.
·>Можно создать иммутабельный объект копируя мутабельные данные

Или литералы-константы, или другие иммутабельные объекты.


·>ну или через передачу владения, собственно всё.

Ес-но.
Об этом и речь, что иммутабельность целиком переезжает на прикладной уровень в джаве, а компилятор умывает руки.
Стоило ли ради этого столько постов трепыхаться? ))


V>>·>Ты тоже что-ли путаешь константность и иммутабельность?
V>>Применительно к данным — это одно и то же.
V>>Применительно к ссылкам/указателям на данные — необходимо уточнять, что имеется ввиду — константность указателя или самих данных.
·>Указатель — это тоже вид данных, не надо мудрствовать.

Именно, как и ссылочная переменная в джаве.
А ты лишь опять сотрясал воздух без понимания определений. ))


V>>Константность можно добавлять неиммутабельным данным по ссылке/указателю, убирать константность нельзя.
V>>То бишь, для любых константных данных их иммутабельность автоматически гарантируется.
·>Иммутабельность гарантируется только тогда, когда к данным нет легального способа получить мутабельный доступ.

Молодец!
Иммутабельность — это иммутабельность!

А константа — это константа!
И для обычных даных это в точности равно иммутабельности.
А для ссылочных данных константность может быть как "приобретаемым позже" свойством, так и неотъемлимым, приобретаемым непосредственно после создания данных (объекта).
Ву а ля!

Я ХЗ где ты тут в 3-х соснах плутаешь. ))


V>>Код, принимающий аргументы по константной ссылке или указателю, может быть одинаков для иммутабельных и неиммутабельных объектов (в части их const-интерфейса) — как прямое следствие возможности добавления к типу модификатора const по указателю/ссылке.
·>Это не достаточное условие.

Это не условие, дурилки картонные, это св-ва инструментария!

Нет абсолютно никакой потребности обеспечивать иммутабельность типа таком коде, достаточно гарантий, что этот код работает в т.ч. с иммутабельными данными.

Это банальное перепендикулярное разделение данных и кода!

Ладно, тут всё ясно.
Кажется, я понял причину твоих трудностей, что ты тут простыни кода исписал уже, ходишь по кругу. ))

Ты зачем-то рассматривал данные и обрабатывающий его код как нечто неразрывное, верно?

Т.е. умудрился в упор не заметить, что иммутабельные и read-only сценарии существенно пересекаются (read-only сценарии являются строгим подмножеством иммутабельных сценариев).

Так вот, иммутабельность обеспечивается на уровне данных и более никак.
А код пишется как read-only или нет.
И на выходе у нас комбинаторика сценариев, а не сумма их.