Sinclair,

> C>Если модификация действительно нужна, то можно использовать const_cast, либо поставить mutable или убрать константность.

> Гм. const_cast полностью противоречит идеологии безопасного программирования.

При наличии run-time проверок -- не в большей степени, чем любое приведение типов. Если бы const вводился в CLI, run-time проверки были бы.

"Проблемы с языками, не поддерживающими const", надуманы в той же степени, что и "проблемы с языками, не поддерживающими индексаторы или свойства". Иными словами, для таких языков можно было бы ввести соглашение, подобное соглашениям по именованию функций доступа к свойствам. Т.е. для каждого reference класса R можно было бы автоматически порождать базовый интерфейс const_R, содержащий константные методы данного класса:

// язык, поддерживающий const

void F(const C c)
{
}

void Main()
{
   C c = new C();
   F(c);
}

// язык, не поддерживающий const

void F(const_C c)
{
}

void Main()
{
   C c = new C();
   F(c);
}

const_cast с точки зрения run-time являлся бы обычным преобразованием типа со всеми вытекающими.

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

_W>Ситуация С# зовет f(const TObject x) из W# — все нормально. Почему C# не должен видеть такие методы? Это ограничение на вызваемую сторону, а не на вызывающую.
Нет. Уже не нормально. Не забывай что поддерживаются функции высших порядков, и делегат может быть как параметром вызова так и возвращаемым значением. То есть, связь в любом случае получается в обе стороны.

С уважением, Gleb

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>const_cast с точки зрения run-time являлся бы обычным преобразованием типа со всеми вытекающими.
А как быть с делегатами, которые могут быть как входными параметрами, так и результатом функции?

С уважением, Gleb.

GlebZ,

> ПК>const_cast с точки зрения run-time являлся бы обычным преобразованием типа со всеми вытекающими.

> А как быть с делегатами, которые могут быть как входными параметрами, так и результатом функции?

Приведи, пожалуйста, конкретный пример, в котором по-твоему будут проблемы...

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>GlebZ,

>> ПК>const_cast с точки зрения run-time являлся бы обычным преобразованием типа со всеми вытекающими.

>> А как быть с делегатами, которые могут быть как входными параметрами, так и результатом функции?

ПК>Приведи, пожалуйста, конкретный пример, в котором по-твоему будут проблемы...

public delegate String MyDelegate( const MyObject obj );
....
MyDelegate myD1 = new MyDelegate( obj.Method());
Delegate resDelegate=MyFunction(myDl);

С уважением, Gleb.

ID> public ArrayList Bar
ID> {
ID> get
ID> {
ID> return ArrayList.ReadOnly(this.bar);
ID> }
ID> }
ID>}
ID>[/c#]

GlebZ,

>>> ПК>const_cast с точки зрения run-time являлся бы обычным преобразованием типа со всеми вытекающими.

>>> А как быть с делегатами, которые могут быть как входными параметрами, так и результатом функции?

> ПК>Приведи, пожалуйста, конкретный пример, в котором по-твоему будут проблемы...
>
>

> public delegate String MyDelegate( const MyObject obj );
> ....
> MyDelegate myD1 = new MyDelegate( obj.Method());
> Delegate resDelegate=MyFunction(myDl);
>

И в чем конкретно здесь будет проблема?

/*
Язык, не поддерживающий const, видел бы все это в таком виде:

public delegate String MyDelegate( const_MyObject obj );
....
MyDelegate myD1 = new MyDelegate( obj.Method());
Delegate resDelegate = MyFunction(myDl);

*/

Здравствуйте, Павел Кузнецов, Вы писали:


ПК>И в чем конкретно здесь будет проблема?

ПК>/*
ПК>Язык, не поддерживающий const, видел бы все это в таком виде:
ПК>

ПК>public delegate String MyDelegate( const_MyObject obj );
ПК>....
ПК>MyDelegate myD1 = new MyDelegate( obj.Method());
ПК>Delegate resDelegate = MyFunction(myDl);
ПК>

ПК>*/
Здоровски, правда делегат это свой тип. На лету переформировывать такое сложновато, так как запрашивается информация рефлекшон из сборки вызывающей. А она не очень понимает что const_MyObject это совсем не MyObject.
а если он сделает так

public void MyMethod(const_MyObject obj)
{
 (obj is INoConstObject).DoFormatHardDiskNaFig();
}

С уважением, Gleb.

GlebZ,

> ПК>Язык, не поддерживающий const, видел бы все это в таком виде:
> ПК>

> ПК>public delegate String MyDelegate( const_MyObject obj );
> ПК>....
> ПК>MyDelegate myD1 = new MyDelegate( obj.Method());
> ПК>Delegate resDelegate = MyFunction(myDl);
> ПК>

> Здоровски, правда делегат это свой тип. На лету переформировывать такое сложновато, так как запрашивается информация рефлекшон из сборки вызывающей. А она не очень понимает что const_MyObject это совсем не MyObject.

Т.е.? const_MyObject и не являлось бы MyObject. const MyObject на уровне языка превращалось бы в const_MyObject на уровне CLI так же, как obj[i] на уровне C# превращается в obj.get_Item(i) на уровне CLI. Соответственно, ничего переформировывать не надо было бы: в сборке уже все было бы в виде "delegate String MyDelegate( const_MyObject obj )".

> а если он сделает так
>

> public void MyMethod(const_MyObject obj)
> {
>  (obj is INoConstObject).DoFormatHardDiskNaFig();
> }
>

>

Его право. Это как минимум не хуже, чем сегодня, т.к. сейчас он может безо всяких преобразований написать просто obj.DoFormatHardDiskNaFig(). Пожалуй, даже лучше, т.к. случайно получить доступ к неконстантным методам он бы уже не мог.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Его право. Это как минимум не хуже, чем сегодня, т.к. сейчас он может безо всяких преобразований написать просто obj.DoFormatHardDiskNaFig(). Пожалуй, даже лучше, т.к. случайно получить доступ к неконстантным методам он бы уже не мог.
Почти. Есть еще CAS который может ограничить использование кода. Без всяких const.

С уважением, Gleb.

GlebZ,

> ПК>Его право. Это как минимум не хуже, чем сегодня, т.к. сейчас он может безо всяких преобразований написать просто obj.DoFormatHardDiskNaFig(). Пожалуй, даже лучше, т.к. случайно получить доступ к неконстантным методам он бы уже не мог.

> Почти. Есть еще CAS который может ограничить использование кода. Без всяких const.

Ты его для таких целей реально используешь?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>GlebZ,

>> ПК>Его право. Это как минимум не хуже, чем сегодня, т.к. сейчас он может безо всяких преобразований написать просто obj.DoFormatHardDiskNaFig(). Пожалуй, даже лучше, т.к. случайно получить доступ к неконстантным методам он бы уже не мог.

>> Почти. Есть еще CAS который может ограничить использование кода. Без всяких const.

ПК>Ты его для таких целей реально используешь?
Подколол? Нет, не было случая. Все объекты которые использую в названиях методов и по возвращаемому результату подразумевают изменяют ли они свое состояние или нет. Как то в отличие от С++ не замечал нужность const.

С уважением, Gleb.

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

C>Тогда как запретить модификацию дочернего объекта возвращаемого через проперти?

Понимаш ли... если мыслить объектами, а не ячейками памяти, то становится понятным, что неизменяемость — это свойство самого объекта, а не окружения в котором он обитает. Соотвественно окружение вольно только отдать ссылку на внутренний объект или не отадать.

При таком взгляде становится понятным, что запрет модификации извне объекта противоречит духу ООП.

Другое дело, что неизменяемость можно было бы декларировать для методов, свойств и классов. Это позволило бы повысить контроль и не допускать ошибки дизайна.

В общем то этот контроль можно сделать и извне. Например, с помощью атрибута и FxCop-а или R#-а.

Джиту же и CLR в целом все это без надобсности. Они и так могут обнаружить неизменяемые сущности.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Неизменяемость объектов можно было бы обеспечить на уровне ВМ. Всё равно барьер записи используется сборщиком мусора.

Барьер записи может исчезнуть как при смене алгоритма ЖЦ, так и при введении оптимизаций в этот алгоритм. Однако для контроля неизменяемости достаточно возможностей компилятора. Просто контролировать нужно не изменение объекта, а физическую возможность класса производить модификацию состояния. Ну, как со static-классами в которые нельзя добавить не static-метод.

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

C>Предлагаю начать собирать подписи. Авось их проймет.

А может собирать подписи за введения mutable, а по умолчанию чтобы все как в ФЯ?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>const вовсе не обязательно означает константность объекта; в большинстве случаев как раз наоборот, он означает константность пути доступа к нему. Например, какой из объектов константен в следующем случае?
ПК>

ПК>class C { };

ПК>void f(C const& c)
ПК>{
ПК>}

ПК>int main()
ПК>{
ПК>   C c;
ПК>   f(c);
ПК>}
ПК>

Вот, дума, именно такие примеры и подталкнули разработчиков C# выкинуть const к чертям. Чтобы люди не тратили время на решение подобных шарад.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Реч идёт о VisualWorks Smalltalk. Но боюсь, что о флаге неизменности найти инфу там будет трудновато. Я нашел обзор.

ANS>Если кратко, то у любого объекта можно установить флаг неизменности (immutability flag). При попытке изменения объекта выбрасывается исключение. В нём, например, можно запомнить изменённый объект, разрешить мутацию и перезапустить операцию. Плюс, со средой идёт фрейворк, который позволяет задавать различные полиси реакции на такое исключение.

И if-ы в рантайме... Короче полный приплыз с точки зрения производительности. Тут народ все думает, как уменьшить накладные расходы связанные с райт-барьером, а эти...

И это при том, что все что унжно можно смело контролировать во врмемя компиляции.

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

VD>Понимаш ли... если мыслить объектами, а не ячейками памяти, то становится понятным, что неизменяемость — это свойство самого объекта, а не окружения в котором он обитает.

неизменяемость — это свойство ссылки на объект, а не самого объекта

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

VD>И это при том, что все что унжно можно смело контролировать во врмемя компиляции.

нельзя.

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

VD>А может собирать подписи за введения mutable
А смысл? immutable в стрингах также нарушается в unsafe.

С уважением, Gleb.