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

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

V>>Вот именно, я об этом и говорю. Но чем этот подход будет отличаться от const_cast'a? Ну да, чисто с эстетической точки зрения красивее, но суть таже.

VD>Вообще-то const_cast тут вообще ни с какого боку не уперся. Более того, он позволяет нарушить данный контракт. А это уже нарушение принципов типобезопасности.

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

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

WH>

WH>using SMByteEps = ConsoleApplication3.StateMachine<byte>.EpsTransition;
WH>

Плохо только, using придется писать для каждого типа и в каждом файле, где они используются.

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

AF>Ну на самом деле в случае C++ отвтственность несет ни одна из этих сторон. Ответственность там несет компилятор.

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

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

WH>>В твоей системе зависимоти не предсказуемые.
AF>С чего ты так решил?
Элементарно:
Допустим у нас есть некий класс типа такого:

public class Foo
{
    public mutable x : int;
    public mutable y : int;
    public mutable z : int;
    public static DoSome(..., fn : Foo -> Foo) : void
    {
        ....
    }
}

Это класс использует все кому не лень както так

    public static Asd(...) : void
    {
        ...
        Foo.DoSome(..., foo => {foo.x = foo.y - foo.z; foo});
        ...
    }
    public static Qwe(...) : void
    {
        ...
        Foo.DoSome(..., foo => {foo.x = foo.y + foo.z; foo});
        ...
    }

Наш мегакомпилятор пронюхал что все работают с Foo как с value типами и все под это дело заоптимизировал.

Теперь вдруг появляется какойто левый код в котором написали чтото типа такого:

    public static Zxc(...) : List<Foo>
    {
        ...
        def fooList = List<Foo>();
        ...
        Foo.DoSome(..., foo => {fooList.Add(foo); foo});
        ...
        fooList
    }

Те вдруг у нас начали работать с Foo как reference типом ибо в по факту у него именно такая семантика.
И по цепной реакции у нас все посыпалось...

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

kan>>Константы времени компиляции в С++ сущность совсем другая, и со словом const они почти никак не связаны.

VD>Это не так.

Гхм…

Автор: c-smile
Дата: 10.01.06

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

VD>Хотя согласен, что идея помечать методы (да и классы) как неизменяемые — это хорошая идея. И надо будет ее реализовать.

На самом деле правильная идея (которая хорошо ложится на философию Немерле) как раз делать их (классы и методы) по умолчанию неизменяемыми, а как раз помечать изменяемые случаи!

А то ведь в основном людям лень дополнительно чего-то дописывать.
поэтому Nemerle провоцирует делать неизменяемые переменные (чтобы не писать mutable),
а C++ — изменяемые (чтобы не писать const) .

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

WH>Те вдруг у нас начали работать с Foo как reference типом ибо в по факту у него именно такая семантика.
WH>И по цепной реакции у нас все посыпалось...

Ничего не посыпалось. Никто не запрещает использовать один и тот же тип как по ссылке, так и по значению в зависимости от контекста.

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

AVK>Понятно, что компилятор. Ты просто не понял мысль — в С++ константность задается как свойство обрабатывающего метода, в шарпе как свойство самих данных. А уж кем конкретно это контроллируется, дело десятое.

В С++ никто не запрещает создавать неизменяемые типы, если есть такая необходимость. А вот создать константную ссылку в шарпе нельзя. В этом и есть главное различие

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

_FR>Гхм…

Автор: c-smile
Дата: 10.01.06

И это тоже.
При некоторых обстаятельствах компилятор порождает именно константы.

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

V>Я точно также могу пометить, метод, который форматирует винчестер (удаляет все объекты, ваш вариант), как якобы безопасный с точки зрения инварианта типов программы (как ты предлагал помечать методы записи в лог) — и приплыли.

Это твои проблемы.

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

AVK>>>Как раз очень правильно. Потому что утилитный метод лучше делать статическим.

AF>>А почему тогда у List<T> его сделали экземплярным?

AVK>Потому что пиип.

Лично я на это дело сморю так. Если в языке есть методы расширения и IDE их понимает, то возможно действительно лучше оформлять утилитарные методы как статические методы расширения. Но если мы имеем дело с языком не поддерживающим методы расширения (C# 1-2), то лучше уж сделать их экземплярными просто для удобства и краткости. Так что ребята писавшие List<T> поступили совершенно верно.

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

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

WH>>

WH>>using SMByteEps = ConsoleApplication3.StateMachine<byte>.EpsTransition;
WH>>

AF>Плохо только, using придется писать для каждого типа и в каждом файле, где они используются.

Тогда переходи на Nemerle . В нем объявляешь:

type SMByteEps = ConsoleApplication3.StateMachine<byte>.EpsTransition;

и используй SMByteEps в любом месте.

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

V>Я точно также могу пометить, метод, который форматирует винчестер (удаляет все объекты, ваш вариант), как якобы безопасный с точки зрения инварианта типов программы (как ты предлагал помечать методы записи в лог) — и приплыли.

Ты точно так же можешь назвать метод форматирования винчестера PrintDocument или ValidateData, и потом вызвавший этот метод программист очень сильно удивится. И что ты этим докажешь?

Здравствуйте, AndrewVK, Вы писали:
AVK>Но в таком раскладе вернемся к тому, от чего пытались уйти — придется делать две реализации одного и того же метода — типизированную и нетипизированную.
Ага. Несмотря на тривиальную реализацию, это не вполне удобно.

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

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

V>>Я точно также могу пометить, метод, который форматирует винчестер (удаляет все объекты, ваш вариант), как якобы безопасный с точки зрения инварианта типов программы (как ты предлагал помечать методы записи в лог) — и приплыли.

VD>Это твои проблемы.

Точно. Это проблемы программиста. Как и в случае с const_cast'ом.

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

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

V>>Я точно также могу пометить, метод, который форматирует винчестер (удаляет все объекты, ваш вариант), как якобы безопасный с точки зрения инварианта типов программы (как ты предлагал помечать методы записи в лог) — и приплыли.

AF>Ты точно так же можешь назвать метод форматирования винчестера PrintDocument или ValidateData, и потом вызвавший этот метод программист очень сильно удивится. И что ты этим докажешь?

То, что это будет аналог const_cast'a. Теже яйца, вид сбоку.

Здравствуйте, Андрей Хропов, Вы писали:

VD>>Хотя согласен, что идея помечать методы (да и классы) как неизменяемые — это хорошая идея. И надо будет ее реализовать.

АХ>На самом деле правильная идея (которая хорошо ложится на философию Немерле) как раз делать их (классы и методы) по умолчанию неизменяемыми, а как раз помечать изменяемые случаи!

Что значит "делать … классы … неизменяемыми" Разве, если объявить все поля класса как readonly (в C#), он не станет сам по себе "неизменяемым"?

АХ>А то ведь в основном людям лень дополнительно чего-то дописывать.

Да и неизменяемые методы нужны, ИМХО, _только_ для изменяемых классов (в неизменяемых классах не может быть изменяемых методов по определению), а классы — по умолчанию неизменяемы, => в изменяемых классах довольно часто надо будет делать методы изменяемыми в то время, как в неизменяемых классах — никогда. Получается, что было бы удобнее всего, если бы в изменяемых классах по-умолчанию методы были бы изменяемыми.

АХ>поэтому Nemerle провоцирует делать неизменяемые переменные (чтобы не писать mutable),

Дело, скорее всего, не в Немерле, а в концепции (функционального программирования), диктуемой языком. Я, когда начал использовать Linq и обработку последовательностей через класс Sequence, так же заметил за собой маниакальное пристрастие к отметке полей класса как readonly и попытке построить архитектуру так, что бы количество [public] set-терров свойств свести к минимуму.

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

V>То, что это будет аналог const_cast'a. Теже яйца, вид сбоку.

Нет, ты просто не понимаешь. От преднамеренных диверсий, равно как и от непробиваемой глупости (которая часто бывает намного хуже по своим последствиям), никакая защита не даст гарантий. Но это не значит, что на защиту надо вообще забить.

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

AF>>Плохо только, using придется писать для каждого типа и в каждом файле, где они используются.

VD>Тогда переходи на Nemerle . В нем объявляешь:

VD>type SMByteEps = ConsoleApplication3.StateMachine<byte>.EpsTransition;

VD>и используй SMByteEps в любом месте.

Блин, вот ведь: всё, как надо :о) А этот type виден на уровне исходников, в пределах сборки или каким-то образом "экспортируется"?

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

VD>Лично я на это дело сморю так. Если в языке есть методы расширения и IDE их понимает, то возможно действительно лучше оформлять утилитарные методы как статические методы расширения. Но если мы имеем дело с языком не поддерживающим методы расширения (C# 1-2), то лучше уж сделать их экземплярными просто для удобства и краткости. Так что ребята писавшие List<T> поступили совершенно верно.

Ага, а потом, если нужно сделать свой нестандартный IList, то сортировку придётся писать отдельно (хорошо, что хоть PowerCollections помогает). Просто это бессмысленно. Неужели было тяжело сделать статический класс с методом Sort, а затем в List просто написать дополнитльный метод?