Почему readonly в CLR не настоящий?
От: varenikAA  
Дата: 21.10.20 03:43
Оценка:
После прочтения The D Programming
Language
Andrei Alexandrescu:

В главе 8 объясняется, почему квалификаторы const и
immutable должны быть транзитивными (свойство, также
известное как глубина или рекурсивность): каким бы
косвенным путем вы ни следовали, рассматривая
«внутренности » неизменяемого объекта, сами данные
должны оставаться неизменяемыми. В противном случае
гарантии, предоставляемые квалификатором immutable,
имели бы силу комментария в коде. Нельзя сказать, что
нечто «до определенного момента » неизменяемо
(immutable), а дальше меняется. Зато можно говорить,
что данные изменяемы до определенного момента, а затем
становятся совершенно неизменяемыми, вплоть до самых
глубоко вложенных элементов. Применив квалификатор
immutable, вы сворачиваете на улицу с односторонним
движением. Мы уже видели, что присутствие квалификатора
immutable облегчает реализацию многих оправдавших себя
идиом, не претендующих на свободу программиста, включая
функциональный стиль и разделение данных между
потоками. Если бы неизменяемость применялась «до
определенного момента », то же самое относилось бы и к
корректности программы.
Точно такой же ход рассуждений
применим и для квалификатора shared. На самом деле, в
случае с shared необходимость транзитивности абсолютно
очевидна.


Думаю об этом постоянно, вот бы в clr было бы также.
☭ ✊ В мире нет ничего, кроме движущейся материи.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.