Re[87]: Когда это наконец станет defined behavior?
От: · Великобритания  
Дата: 31.08.23 19:10
Оценка:
Здравствуйте, vdimas, Вы писали:

v> V>>·>Иммутабельность нельзя через view обеспечить.

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

v> Если протечек ссылок для мутабельности нет, то автоматом получается иммутабельность.

Это я и написал ниже.
Вопрос в том, как же компилятор проверяет/помогает гарантировать отстуствие протечек с помощью const? Ответ — да никак. Вывод — const бесполезен для иммутабельности.

v> ·>Можно создать иммутабельный объект копируя мутабельные данные

v> Или литералы-константы, или другие иммутабельные объекты.
Не понял твоё дополнение. Ты предлагаешь копировать литералы-константы, или другие иммутабельные объекты? Зачем? Важное свойство иммутабельных объектов в том, что их копии никак не отличимы от оригинала и копирование можно избегать.

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

v> Ес-но.
v> Об этом и речь, что иммутабельность целиком переезжает на прикладной уровень в джаве, а компилятор умывает руки.
Как и в Плюсах.

v> ·>Указатель — это тоже вид данных, не надо мудрствовать.

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

v> V>>То бишь, для любых константных данных их иммутабельность автоматически гарантируется.

v> ·>Иммутабельность гарантируется только тогда, когда к данным нет легального способа получить мутабельный доступ.
v> Молодец!
v> Иммутабельность — это иммутабельность!
v> А константа — это константа!
Ровно твои слова же: "Если протечек ссылок для мутабельности нет, то автоматом получается иммутабельность". К чему сарказм-то?

Вопрос в том, как собственно обеспечить отсутствие протечек. И где что там у тебя автоматически гарантируется-то с помощью const?
Допустим, у тебя есть где-то const SomeThing someValue(42); — ты гарантируешь, что someValue — иммутабельно?

v> И для обычных даных это в точности равно иммутабельности.

Повторюсь. Данные — не объекты (если я правильно понял, что ты подразумеваешь под данными). Мы говорим об объектах.

v> А для ссылочных данных константность может быть как "приобретаемым позже" свойством, так и неотъемлимым, приобретаемым непосредственно после создания данных (объекта).

v> Ву а ля!
Приобретаемым как? Только заботой программиста. Компайлер c const ничего гарантировать не может.
В java record — гарантии есть, кстати.

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

Ты вообще в двух соснах запутался. Да, каждый иммутабельный объект — константный, но это скучно. Важно то, что не каждый константный объект — иммутабельный. Следовательно константность никак не гарантирует иммутабельности. Это ложится на программиста, что в плюсах, что в джаве, что в шарпах. const для иммутабельности не нужен. Нужен record.

v> ·>Это не достаточное условие.

v> Это не условие, дурилки картонные, это св-ва инструментария!
v> Нет абсолютно никакой потребности обеспечивать иммутабельность типа таком коде, достаточно гарантий, что этот код работает в т.ч. с иммутабельными данными.
Так откуда ты берёшь эти гарантии-то? Рассказывай уже, не томи.

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

Иммутабельность она и в африке иммутабельность.

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

Нет, не подмножеством. read-only view для мутабельного объекта — не подмножество иммутабельного сценария, ну никак.

v> Так вот, иммутабельность обеспечивается на уровне данных и более никак.

v> А код пишется как read-only или нет.
v> И на выходе у нас комбинаторика сценариев, а не сумма их.
Осталось понять ценность этого комбинаторного усложнения на ровном месте, это и есть основная тема этого обсуждения. Мой тезис в том, что иммутабельность — нужна и важна, константность — не является необходимостью и можно нафиг выкинуть, что собственно и сделали в шарпах-явах. Тогда нафиг никакой комбинаторики и всё просто.
avalon/3.0.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.