GlebZ wrote:

> OE>о, кстати этот вопрос я тоже пока не догнал, можно поподробнее — есть
> ссылочный тип, есть метод, в который он передается в качестве параметра
> и который его изменять не должен, только читать — как это разруливается
> в C#?
> В С# это никак не обрабатывается. Единственный способ — это вообще не
> создавать методов меняющих внутреннее состояние объекта. Пример того что
> это работает — String.
А как разрулить такую ситуацию?

class User
{
  void setUserName(string name);
  string getUserName() const;
};

class Form
{
  editUser(User *user);      // а вот тут я ожидаю, что может быть изменено что угодно.
  showUser(const User *user);// вызывая этот метод, я ожидаю, что никто ничего в объекте не поменяет.
};

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

kan>Потому что это единственный (мне известный) язык (не функциональный) где есть const.
kan>Автор вопроса о const явно подразумевал C#, на крайняк CLI, что явно не функциональные языки.
И много ты знаешь чисто функциональных языков?
Подавляющие большинство функциональных языков позволяют писать в императивном стиле. А если посмотреть на nemerle то код на нем вобще можно сделать 1 в 1 (за исключением мелких синтаксических отличий) как на C#.

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

kan>А как разрулить такую ситуацию?

class User
{
  User& setUserName(string name); 
  string getUserName() const;
};

class Form
{
  showUser(editUser(user));// Примерно так
};

При любом изменении создаем новый экземпляр. Ессно при таком подходе важно наличие GC.

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

V>Но факт остается фактом: попытка вызвать метод, который меняет состояние, это фактически попытка вызова закрытого в данном контексте метода. Для закрытия методов в зависимости от контекста имеются штатные механизмы. Да, писанины выходит больше, но, зато все очень гибко и понятно. Идея с модификатором, конечно, хороша, но у нее есть один приличный косяк: как определять, меняет ли метод внутреннее состояние объекта, или не меняет? Вот чтобы рещить эту проблему и придется добавлять всякие консткасты, за использование которых джедаи потом "бъют морды".
Косяка тут нет. Определить изменяет ли метод внутреннее состояние, является ли это состояние закрытым — легко. Единственное где можно изменять состояние это конструктор и методы им вызываемые. Для компилятора у которого есть AST с семантикой — это детская задачка.

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

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

V>>Но факт остается фактом: попытка вызвать метод, который меняет состояние, это фактически попытка вызова закрытого в данном контексте метода. Для закрытия методов в зависимости от контекста имеются штатные механизмы. Да, писанины выходит больше, но, зато все очень гибко и понятно. Идея с модификатором, конечно, хороша, но у нее есть один приличный косяк: как определять, меняет ли метод внутреннее состояние объекта, или не меняет? Вот чтобы рещить эту проблему и придется добавлять всякие консткасты, за использование которых джедаи потом "бъют морды".
GZ>Косяка тут нет. Определить изменяет ли метод внутреннее состояние, является ли это состояние закрытым — легко. Единственное где можно изменять состояние это конструктор и методы им вызываемые. Для компилятора у которого есть AST с семантикой — это детская задачка.

Re[6]: Нет возможности использовать константные ссылки

Автор: prVovik
Дата: 10.11.06

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

kan>>А в каком языке есть const, но нет const_cast?
GZ>Есть понятие mutable/unmutable. Оно в функциональных языках часто присутсвует. Причем unmutable(неизменяемый) — это основной стиль.

Константность объекта и константность ссылки на него — разные вещи. Я подозреваю, что "в функциональных языках" под "unmutable(неизменяемый)" понимают неизменяемость ссылки, а вовсе не данных, на которые она указывает.

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

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

kan>>>А в каком языке есть const, но нет const_cast?
GZ>>Есть понятие mutable/unmutable. Оно в функциональных языках часто присутсвует. Причем unmutable(неизменяемый) — это основной стиль.

_FR>Константность объекта и константность ссылки на него — разные вещи. Я подозреваю, что "в функциональных языках" под "unmutable(неизменяемый)" понимают неизменяемость ссылки, а вовсе не данных, на которые она указывает.

immutable i=10;
mutable i=10;

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

V>Re[6]: Нет возможности использовать константные ссылки

Автор: prVovik
Дата: 10.11.06

И что? Ссылка на класс immutable, сам экземпляр mutable. И еще наверняка singleton. Нормально и без косяков.

GlebZ wrote:
> При любом изменении создаем новый экземпляр. Ессно при таком подходе
> важно наличие GC.
А теперь представь, что у тебя сеть объектов. Каждый раз будешь всю сеть
клонировать?

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

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

V>>Re[6]: Нет возможности использовать константные ссылки

Автор: prVovik
Дата: 10.11.06

GZ>И что? Ссылка на класс immutable, сам экземпляр mutable. И еще наверняка singleton. Нормально и без косяков.

Можно ли вызывать методы, которые пишут что-то в лог, у объекта по immutable ссылке?

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

C>GlebZ wrote:
>> При любом изменении создаем новый экземпляр. Ессно при таком подходе
>> важно наличие GC.
C>А теперь представь, что у тебя сеть объектов. Каждый раз будешь всю сеть
C>клонировать?
Не-а. Тут как раз и есть плюсы такого подхода. Для того чтобы получить другую сеть не обязательно клонировать объекты. Один и тот же объект неизменяем и может лежать в любой подсети. Меняется ведь только ссылка на него.

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

V>>>Re[6]: Нет возможности использовать константные ссылки

Автор: prVovik
Дата: 10.11.06

GZ>>И что? Ссылка на класс immutable, сам экземпляр mutable. И еще наверняка singleton. Нормально и без косяков.

V>Можно ли вызывать методы, которые пишут что-то в лог, у объекта по immutable ссылке?
Конечно. А разве в этом есть противоречие? Даже сам объект который пишет в лог может быть immutable

public class Logs
{
    static string fileName;
    public static void WriteLog(string logString)
    {
        using (StreamWriter sw=File.OpenWrite(fileName))
        {
            sw.WriteLine(logString);
        }
    }
}

Данное ограничение ни на временные объекты, ни на файл не накладываются.

GlebZ wrote:

Ок. Представляю себе цирк:

class User
{
   User& setUserName(string name);
   string getUserName() const;
   User& setUserAge(int age);
   ing getUserName() const;
   User& setUserHeight(float age);
   float getUserHeigh() const;
};

User user = new User();
user = user.setUserName("a");
user = user.setUserAge(30);
user = user.setUserHeight(175.2);

Что хорошо в фукнциональнище не всегда хорошо в императивщине.

> При любом изменении создаем новый экземпляр. Ессно при таком подходе
> важно наличие GC.
Объект соответствует записи в субд. Ку?

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

kan>User user = new User();
kan>user = user.setUserName("a");
kan>user = user.setUserAge(30);
kan>user = user.setUserHeight(175.2);
Сколько императивной писанины. Ведь можно в одну строку.

User user=new User().setUserName("a").setUserAge(30).setUserHeight(175.2);// без возврата такое не сделаешь

или

User user=new User("a", 30, 175.2);

kan>Что хорошо в фукнциональнище не всегда хорошо в императивщине.
Никакой проблемы тут нет.

>> При любом изменении создаем новый экземпляр. Ессно при таком подходе
>> важно наличие GC.
kan>Объект соответствует записи в субд. Ку?
И что Ку? Если тебе нужна транзакционность объектов то это на форум Архитектуры. Она обычно делается внешними средствами. К данной проблематике отношение не имеет.

GlebZ wrote:

> User user=new User().setUserName("a").setUserAge(30).setUserHeight(175.2);// без возврата такое не сделаешь
Если в set-методах возвращать this, то можно такое писать при желании.
Блин, так и думал что ты это предложишь. Но это тоже костыль, сразу надо было посложнее пример накатать:

User user = new User();
placeOnForm1(user);// отображать текущее состояние объекта, объект туда отдаётся константный.
user.setUserName("a");
placeOnForm2(user);// отображать текущее состояние объекта, объект туда отдаётся константный.
if(weNeedSetAge) user = user.setUserAge(30);
user.invalidate();// обновить отображалки
// (можно делать обновление без этого явного метода, в каждом сеттере, зависит от задачи).
user = user.setUserHeight(175.2);
user.invalidate();// обновить отображалки.

Я прекрасно понимаю, что аналогичный код можно переписать в функциональном стиле, но зачем? Императивныые языки нужны
для того, чтобы писать в императивном стиле. А в этом случае const весьма полезен.

> kan>Что хорошо в фукнциональнище не всегда хорошо в императивщине.
> Никакой проблемы тут нет.
Если на императивном языке пишут в функциональном стиле — это проблема, неправильно выбрали язык.

>> > При любом изменении создаем новый экземпляр. Ессно при таком подходе
>> > важно наличие GC.
> kan>Объект соответствует записи в субд. Ку?
> И что Ку? Если тебе нужна транзакционность объектов то это на форум
> Архитектуры. Она обычно делается внешними средствами. К данной
> проблематике отношение не имеет.
В общем можно, но слишком сфероконично.

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

V>>>>Re[6]: Нет возможности использовать константные ссылки

Автор: prVovik
Дата: 10.11.06

GZ>>>И что? Ссылка на класс immutable, сам экземпляр mutable. И еще наверняка singleton. Нормально и без косяков.

V>>Можно ли вызывать методы, которые пишут что-то в лог, у объекта по immutable ссылке?
GZ>Конечно. А разве в этом есть противоречие? Даже сам объект который пишет в лог может быть immutable
GZ>

GZ>public class Logs
GZ>{
GZ>    static string fileName;
GZ>    public static void WriteLog(string logString)
GZ>    {
GZ>        using (StreamWriter sw=File.OpenWrite(fileName))
GZ>        {
GZ>            sw.WriteLine(logString);
GZ>        }
GZ>    }
GZ>}
GZ>

GZ>Данное ограничение ни на временные объекты, ни на файл не накладываются.

А на консоль? А на сеть? А на ремотинг? А на WinAPI вызовы? Список можно продолжать.

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

V>А на консоль? А на сеть? А на ремотинг?
На здоровье. В remoting ты же получаешь при сериализации — клон, а не сам объект.
V>А на WinAPI вызовы? Список можно продолжать.
Так ведь никто и не предлагал сделать все объекты immutable. Если сделать все объекты таковыми, то получится чисто функциональный язык. А этого никто и не предлагал.

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

kan>Я прекрасно понимаю, что аналогичный код можно переписать в функциональном стиле, но зачем? Императивныые языки нужны
kan>для того, чтобы писать в императивном стиле. А в этом случае const весьма полезен.
Видишь ли, никто и не предлагал отказаться от mutable объектов. В данном случае очень показательны константные строки в C++. Там есть режим компиляции(по моему во многих компиляторах) когда константная строка единая на все приложение. То есть, если ты делаешь:

strcpy(s, "bla");
strcpy(s1, "bla");

строка "bla" указывает на одну и ту же область памяти. И заметь это никому и не мешает. В С# imho immutable технологически это сделать легче. Там так строки уже работают. В C++ вся идея изгажена тем, что константу можно перевести в указатель без константы, и соответсвенно нарушить данное правило.

kan>Если на императивном языке пишут в функциональном стиле — это проблема, неправильно выбрали язык.
Нет. Если ты посмотришь на все введения в императивные языки за последние 5 лет, то все они пришли из функциональных языков. К тому же, например C# особенно трешка, напрямую поддерживает функциональное программирование. Только менее императивным он не стал. Или например, если возьмешь к примеру STL — то это прямая эмуляция функций высшего порядка.

GlebZ wrote:

> kan>Я прекрасно понимаю, что аналогичный код можно переписать в
> функциональном стиле, но зачем? Императивныые языки нужны
> kan>для того, чтобы писать в императивном стиле. А в этом случае const
> весьма полезен.
> Видишь ли, никто и не предлагал отказаться от mutable объектов. В данном
Так разговор идёт о const — позволяет делать что-то типа мутабельности (но не совсем её) на уровне методов, притом
проверка compile-time (!), а не "as documented". Как в C# узнать, что данный объект немутабельный? Правильно — залезть в
документацию (если она есть, иначе — сорцы, если они есть, иначе — вешаться) и прочитать. Больше никак. Как узнать, что
данный метод можно вызвать без клонирования объекта, дабы чьи-нибудь данные не попортить? Правильно — залезть в
сорцы/документацию. Больше никак.
А если вдруг какой-нибудь метод изменили и он стал изменять состояние? Старый код об этом никак не узнает.

> случае очень показательны константные строки в C++. Там есть режим
Не понял что этот пример показывает... просто оптимизация, сташвая возможной, благодая нестрогости стандарта.

> легче. Там так строки уже работают. В C++ вся идея изгажена тем, что
> константу можно перевести в указатель без константы, и соответсвенно
Это как? Без явного приведения?

> нарушить данное правило.
Нет, идея С++ в том, что он небезопасный — можно нарушить любое правило.

> kan>Если на императивном языке пишут в функциональном стиле — это
> проблема, неправильно выбрали язык.
> Нет. Если ты посмотришь на все введения в императивные языки за
> последние 5 лет, то все они пришли из функциональных языков. К тому же,
> например C# особенно трешка, напрямую поддерживает функциональное
> программирование. Только менее императивным он не стал. Или например,
Как именно поддерживает? Чем эта поддержка принципиально отличается от C++? Можно ссылку.

> если возьмешь к примеру STL — то это прямая эмуляция функций высшего
> порядка.
Мягко говоря, не очень... скорее тут "виноваты" шаблоны, stl не при чём, а это исчисление типов, метапрограммирование.

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

WH>Те предлогаешь каждый раз когда в системе появляется новый код перекомпилировать всю систему?

Ты будешь смеяться, но и в этом может быть смысл. Например, если нужно выжать из системы максимум производительности — в этом случае тотальная кросс-оптимизация всех модулей будет вполне уместна.
В любом случае, код, от которого зависят все остальные модули, меняется не так уж и часто.