Здравствуйте, VladD2, Вы писали:
Д>>неизменяемость — это свойство ссылки на объект, а не самого объекта
VD>Уверен? А как же string, DateTime и т.п.?
это просто особенности .NET-ной реализации
небольшой реверанс в сторону ФЯ
на самом же деле есть два подхода к этому вопросу
первый — это как раз ФЯ, где все объекты неизменяемы, а при необходимости изменить данные создается копия
второй — это обычный подход ИЯ, где разрешение или запрещение модификации объектов управляется ссылками на них, как например в C++
void foo(int& x)
{
a = 5;
}
void bar(const int& x)
{
a = 10; // хрен вам! :)
}
int a = 0;
foo(a);
bar(a);
VD>Ну, а неизменяемость ссылки можно добиться банальной инкапсуляцией. Используй свойства без сеттеров и будет тебе щастье.
заводить дополнительный неизменяемый интерфейс? я так и делаю, когда припрет. Другой вопрос, что
1. Это все равно костыли
2. Требует дополнительного ручного кодирования
полагаю, что такой распространенный паттерн следовало бы встроить в яызк
Здравствуйте, VladD2, Вы писали:
VD>>>И это при том, что все что унжно можно смело контролировать во врмемя компиляции.
ANS>>нельзя.
VD>Серьезный аргумент.
Твоя школа
А если, серьёзно, то проверку времени компиляции, можно использовать только во время компиляции, а ошибку времени выполнения, можно и во время выполнения. Пример, использования при работе с некой БД я как раз и привёл.
Здравствуйте, Дарней, Вы писали:
Д>это просто особенности .NET-ной реализации Д>небольшой реверанс в сторону ФЯ
Это реверанс в сторону дефрагментирующего GC. Он не очень любит изменяемые по длине массивы.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>>>И это при том, что все что унжно можно смело контролировать во врмемя компиляции.
ANS>>>нельзя.
VD>>Серьезный аргумент.
ANS>Твоя школа
ANS>А если, серьёзно, то проверку времени компиляции, можно использовать только во время компиляции, а ошибку времени выполнения, можно и во время выполнения. Пример, использования при работе с некой БД я как раз и привёл.
Мы все еще ведем речь о константности? Причем тут БД?
Еще раз. Что мне потенциально помешает переложить контроль изменения объектов на джит? Предположим, что у каждого метода есть признак того что он не изменяет содержимое экземпляра и параметров. Далее остается только проверить, что все код обращающися к экземпляру вызвает только такие методы и не пытается самостоятельно изменить содержимое экземпляра.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ANS>>А если, серьёзно, то проверку времени компиляции, можно использовать только во время компиляции, а ошибку времени выполнения, можно и во время выполнения. Пример, использования при работе с некой БД я как раз и привёл.
VD>Мы все еще ведем речь о константности? Причем тут БД?
VD>Еще раз. Что мне потенциально помешает переложить контроль изменения объектов на джит? Предположим, что у каждого метода есть признак того что он не изменяет содержимое экземпляра и параметров. Далее остается только проверить, что все код обращающися к экземпляру вызвает только такие методы и не пытается самостоятельно изменить содержимое экземпляра.
Ничего, кроме того, что для убеждения в том, что метод объект не меняет, частенько нужно будет этот метод выполнять. В конкретном контексте, естественно.
Здравствуйте, VladD2, Вы писали:
VD>Вот, дума, именно такие примеры и подталкнули разработчиков C# выкинуть const к чертям. Чтобы люди не тратили время на решение подобных шарад.
Влад, вот ты ведь умный квалифицированный программист, и С++ знаешь, так чего ж говоришь такие флеймовые глупости?
Здравствуйте, VladD2, Вы писали:
VD>Понимаш ли... если мыслить объектами, а не ячейками памяти, то становится понятным, что неизменяемость — это свойство самого объекта, а не окружения в котором он обитает. Соотвественно окружение вольно только отдать ссылку на внутренний объект или не отадать.
VD>При таком взгляде становится понятным, что запрет модификации извне объекта противоречит духу ООП.
Ничему оно не противоречит, ибо ортогонально.
Простой пример из жизни — всеми любимый Microsoft Word.
Когда ты открываешь файл из диалога File -> Open, ты можешь нажать как кнопочку Open, так и кнопочку Open Read-Only, а также Open as Copy.
const в С++ — это именно та самая кнопочка Open Read-Only.
Декларация о намерениях пользователя и о его желаниях работать с объектом определенным образом (в данном случае — получая гарантии, что объект изменить не удастся, даже если он и неконстантный по сути).
Еще пример — файл в файловой системе, доступный для изменения одним пользователям и недоступный другим.
Никакого отношения к intrinsic неизменяемости самого файла (потому что она зависит совершенно от других вещей, например, от того, что файл находится на CD, а не на винте) способ доступа не имеет. Очевидно, что файл, лежащий на винте, является изменяемым, его можно стереть и еще много всяких вкусностей сделать.Однако если ты не хочешь, чтобы файл был случайно изменен, ты повесишь на него флажок read-only и получишь искомые гарантии от файловой системы, аналогичные гарантиям, которые получает программист C++ от компилятора, используя const. При этом файл вполне может оставаться не read-only для других пользователей.
Здравствуйте, jazzer, Вы писали:
J>Простой пример из жизни — всеми любимый Microsoft Word. J>Когда ты открываешь файл из диалога File -> Open, ты можешь нажать как кнопочку Open, так и кнопочку Open Read-Only, а также Open as Copy.
Ворд фиговая аналогия. Он говорят на чистом С написан.
Что же до этого дела, то эти варианты могут быть организованы созданием разных обхектов или примененеием паттернов.
J>const в С++ — это именно та самая кнопочка Open Read-Only.
Ненадо провдить столь тонких аналогий со столь разными вещами.
J>Декларация о намерениях пользователя и о его желаниях работать с объектом определенным образом (в данном случае — получая гарантии, что объект изменить не удастся, даже если он и неконстантный по сути).
С точки зрения объекта именно он должен управлять своим состоянием. Если у того же документа ворда есть понятие Read-Only, то он должен генерировать исключения или возвращать код ошибки при попытке вызвать метод записи на диск. Но при этом сам документ остается редактируемым. Я могу изменить его как хочу и записать под другим именем.
Так что это как раз контроль скорее на уровне объекта. В нем ввели один флаг который проверяют в методе записи на диск.
J>Еще пример — файл в файловой системе, доступный для изменения одним пользователям и недоступный другим.
Ну, вот и представь себе. Есть объект отвечающий за открытый файл. В общекте вроде как запись совершить нельзя. Но отвечает за это один флаг. Так вот переменная указывающая на этот объект говорит, что я не могу менять этот флаг (да и весь объект), но я беру и делаю тайп_каст... в итоге я меняю флаг и пишу в защещенный от записи файл. Для С++ ситуация может и нормальная. Моле нефига объект держать в том же процессе ОС. А для управляемого кода ситуация не допустимая. Так что если этот const нельзя проконтролировать везде, то это уже не хорошее решение — дырка.
J>Продолжать примеры? Рассказать про GRANT в SQL?
Не стоит. Эти уже не состоятельны. Вообще делая столь далекие аналогии можно даже не напрягаться. Все равно ни на что кроме красноречия не годятся.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
VD>>Вот, дума, именно такие примеры и подталкнули разработчиков C# выкинуть const к чертям. Чтобы люди не тратили время на решение подобных шарад.
J>Влад, вот ты ведь умный квалифицированный программист, и С++ знаешь, так чего ж говоришь такие флеймовые глупости?
Понимаш ли. То что тебе что-то кажется глупостью еще не означает, что это так на самом деле. Я просто уверен, что одна из причин по которой было решено не связываться с const или readonly было то, что это усложнит понимание программ. Ведь действительно readonly на указатель ещене значит readonly на объект.
В C#, как не странно это уже кое как проявилось. В нем есть ключевое слово readonly которое можено применять к полям. Однако означает оно именно константность полей (переменных, значит). Так что одна из забавных ошибок выглядит так:
class A
{
public readonly int[] Array = new int[10];
}
...
A a = new A();
a.Array[0] = 1; // типа не сработает, так как readonly.
В итоге используется это readonly раз в год, а объяснять разным орлам, "почему не сработало ваше земное притяжение" (с) Альф приходится постоянно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Ничего, кроме того, что для убеждения в том, что метод объект не меняет, частенько нужно будет этот метод выполнять. В конкретном контексте, естественно.
Ерунду не говори. Чтобы понять что метод не меняет содержимое параметров достаточно проанализировать его мсил.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ANS>>Ничего, кроме того, что для убеждения в том, что метод объект не меняет, частенько нужно будет этот метод выполнять. В конкретном контексте, естественно.
VD>Ерунду не говори. Чтобы понять что метод не меняет содержимое параметров достаточно проанализировать его мсил.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>Ерунду не говори. Чтобы понять что метод не меняет содержимое параметров достаточно проанализировать его мсил.
ANS>
ANS>if (bFlag)
ANS> setValue(value);
ANS>
И что? Если есть ссылка на метод модифицирующий состояние, значит все... метод уже не является константным. Анализ не может основываться на состоянии объекта.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>И что? Если есть ссылка на метод модифицирующий состояние, значит все... метод уже не является константным. Анализ не может основываться на состоянии объекта.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>И что? Если есть ссылка на метод модифицирующий состояние, значит все... метод уже не является константным. Анализ не может основываться на состоянии объекта.
ANS>Ну! А я тебе о чем говорю?
Я не понял о чем ты говоришь, но анализу это не мешает. Если такой код есть, то метод помечается как модифицирующий состояние и все дела.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
