После прочтения The D Programming
Language
Andrei Alexandrescu:
В главе 8 объясняется, почему квалификаторы const и
immutable должны быть транзитивными (свойство, также
известное как глубина или рекурсивность): каким бы
косвенным путем вы ни следовали, рассматривая
«внутренности » неизменяемого объекта, сами данные
должны оставаться неизменяемыми. В противном случае
гарантии, предоставляемые квалификатором immutable,
имели бы силу комментария в коде. Нельзя сказать, что
нечто «до определенного момента » неизменяемо
(immutable), а дальше меняется. Зато можно говорить,
что данные изменяемы до определенного момента, а затем
становятся совершенно неизменяемыми, вплоть до самых
глубоко вложенных элементов. Применив квалификатор
immutable, вы сворачиваете на улицу с односторонним
движением. Мы уже видели, что присутствие квалификатора
immutable облегчает реализацию многих оправдавших себя
идиом, не претендующих на свободу программиста, включая
функциональный стиль и разделение данных между
потоками. Если бы неизменяемость применялась «до
определенного момента », то же самое относилось бы и к
корректности программы.
Точно такой же ход рассуждений
применим и для квалификатора shared. На самом деле, в
случае с shared необходимость транзитивности абсолютно
очевидна.
Думаю об этом постоянно, вот бы в clr было бы также.
Здравствуйте, varenikAA, Вы писали:
AA>В главе 8 объясняется, почему квалификаторы const и immutable должны быть транзитивными
AA>Думаю об этом постоянно, вот бы в clr было бы также.
Зачем мечтать о том, чего никогда не будет??
D писался умным прогером для умных юзеров. C# писался посредственностями для посредственностей. D развивается в сторону полезных фич, C# — в сторону "популярных плюшек", причём последний ещё и сдавлен грузом совместимости.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, varenikAA, Вы писали:
AA>>В главе 8 объясняется, почему квалификаторы const и immutable должны быть транзитивными
AA>>Думаю об этом постоянно, вот бы в clr было бы также.
K>Зачем мечтать о том, чего никогда не будет?? D писался умным прогером для умных юзеров. C# писался посредственностями для посредственностей. D развивается в сторону полезных фич, C# — в сторону "популярных плюшек", причём последний ещё и сдавлен грузом совместимости.
Ты пишешь на D?
Здравствуйте, varenikAA, Вы писали:
AA>>Думаю об этом постоянно, вот бы в clr было бы также.
Наоборот, в mutable-мире — нужно больше пространства для маневра. Эти констрейны обычно имеют смысл в какой-то области видимости. Например десериализатор конструирует объект, а потребителю, мы хотим его выставить как рид-онли, при этом мы не хотим иметь 1001-у обертку и рантайм проверок. Хэндл файла в классе — ридонли для всех его членов, кроме конструктора и, возможно деструктора (нигде такого нет, спорно).
AA>Подумал. допустим даже "только чтение" не означает "неизменяемость". ну, ок!
AA>Тогда зачем в новую версию завезли init only???!!!!
Подумай ещё. Применений и так хватает, все же есть в документации.
Например, static readonly поле позволяет JIT-у трактовать его как константу, в рантайме, выбрасывая все бранчи которые никогда не могут случиться. При чем эта константа может быть инициализирована в статическом конструкторе.
AA>Но уже давно для clr есть F# в котором by default родные структуры иммутабельны.
Применение настоящей иммутабельности обосновано, там где это подходит. А в практических областях — очень больно сопрягается с реальной жизнью, и даже при всем желании авторов, не всегда ее удается достичь с приемлимыми характеристиками потребления памяти или временем выполнения. Иначе говоря, очень хорошо, когда оно подходит, и плохо когда оно не подходит. Поэтому, представлять весь мир в виде гвоздей и предлагать один молоток — то это как раз тот подход, когда, заранее известно, что он не работает. Нужно и то и другое.
AA>А без них нет будущего на многоядерных системах.
Это вообще пофигу, есть задачи которые не распараллеливаются, или подходы для этого неизвестны. Возьми стальной шар и 4-х слесарей с 4-мя ножовками. Увидишь, что один справится быстрее и почти без матов.
