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

GZ>>Кому как. Нет ни одной типа коллекции которую я бы не юзал. Все пригождается.

AF>Проблема не в том, что есть "лишние" типы коллекций. Проблема в том, что между ними слишком много мелких неприятных различий. Почему например для массивов есть ко/контра-вариантность,

Да ещё и для не любых массивов! :о))

AF>а для других коллекций — нет?

потому что способ хранения данных в массиве известен рантайму, а вот как хранятся данные за ширмой IList\ICollection — личное дело того, кто эти интерфейсы реализует. Опять же, при необходимости, написание своего преобразователя совсем не сложно (во-первых) и в третьем шарпе у экземпляра любого типа, реализующего IEnumerable (который не-дженерик!) можно будет вызвать метод Cast<T>() получив последовательность (IEnumerable<T>) нужного типа. И это лишь один из способов. Для Немерла, небось, тоже кудесники могут много чего придумать — надо только захотеть.

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

WH>>Решается метапрограммированием. И вобще наследование реализации нужно по возможности избегать. Ибо оно дает слишьком сильные связи что мешает развивать систему.
AF>Метапрограммированием решается вообще всё — это не аргумент.
А как насчет сильной связанности?

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

WH>>Дело в том что есть объекты которые должны быть изменяемыми и есть объекты которые должны быть не изменяемыми.
AF>Чушь.
Как скажите молодой человек.

AF>>>Нет кортежей.
WH>>Легко эмулируются при помощи генериков.
AF>а ты пробовал?
Пробовал. Получилось при помощи одного генерик класса и одного класса заглушки. С их помощью можно генерировать кортежи произвольной длинны. Если у тебя не хватает фантазии то это не мои проблемы.

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

AF>Проблема не в том, что есть "лишние" типы коллекций. Проблема в том, что между ними слишком много мелких неприятных различий.
Тебе не нравится

void Printf(object[] obj)
{
...    
}
int[] range=new int[]
...
Printf(range);

Напиши в Microsoft. Может уберут. Но я здесь тебе не помошник.
AF>Почему например для массивов есть ко/контра-вариантность, а для других коллекций — нет?
Для каких других? Основная проблема в том, что другие коллекции являются либо коллекциями object либо generics. То что касается generics то это ограничение C#. В С++/CLI насколько я помню такое можно делать. И насколько я помню, это поддерживается именно CLI.

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

AF>Если у кого-то есть желание расширить список — welcome.

Расширение или сужение зависит от точки зрения и имеющегося багажа знаний. Так что лучше для начала пару коментариев.

AF>Нет ни множественного наследования реализаций, ни его заменителей.

Это проблемы не CLI, а кокретных ЯП. Так есть Эфил с МН, Скала с трэтсами и Немерле с макросами на которых она неплохо заменяется.

AF>Нет ковариантности для переопределения виртуальных методов.

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

AF>Нет возможности использовать константные ссылки на объекты, что вынуждает программиста создавать read-only версии объектов — дополнительная ручная работа.

Мне кажется, что вопрос изменчивости данных — это отдельный и очень непростой вопрос. И рассматривать его только в аспекте неизменчивости ссылок в корне не верно. Ведь единственно зачем нужно обсуждать этот вопрос — это чтобы понять как получить более надежные и безопасные ЯП. Пример С++ же отлично показывает, что наличие неизменяемости ссылок не делает язык более безопасным.

AF>Нельзя перегружать методы по типу возвращаемого значения.

CLI это позволяет делать. Это не позволяют делать C++ и C#. И на то есть вполне объективные причины. Кстати, оператор приведения типов в Шарпе перегружается именно по типу возвращаемого значения.

AF>Нет кортежей.

Это возможность скорее языковая.

AF>Критически важные системные исключения (OutOfMemoryException, ThreadAbortException, ExecutionEngineException и т.п.) наследуются от того же базового класса, что и частно используемые ArgumentException, NotSupportedException и так далее. Это провоцирует плохих программистов писать конструкции наподобие
AF>catch (Exception) { return false; }

Откровенно говоря никогда не видел в этом проблемы, но судить не возьмусь.

AF>Наличие типов, которые явно обозначаются как передаваемые через стек, и все связанные с этим усложнения системы типов (боксинг) и ограничения (нельзя наследовать от структур). На самом деле, решать, каким образом передавать объект в каждом конкретном случае – это задача оптимизатора.

От тут полностью согласен. Вот только жаль, что такого умного оптимизатора пока реально нет. В Яве над этим ведется работа. Поглядим что выйдет.

AF>Просчеты в реализации энумов. Например, любое числовое значение можно привести к любому перечислимому типу, даже если в том нет соответствующего значения, и это не вызовет никакой ошибки во время выполнения. Фактически, целевой переменной перечислимого типа будет присвоено некоторое «неопределенное» значение. No comments.

Опять же не видел от этого проблемы. Хотя с аргументами согласен.

AF>Коллекции
AF>Одновременное применение в системе типов .NET массивов, нетипизированных коллекций, специализированных коллекций и генерик-коллекций, которые все «немного похожи» и «немного разные». Соответственно, методы из FCL возвращают разные типы — это создает лишнюю путаницу и сложности при программировании.

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

AF>Например, String.Split возвращает string[], а не IList<string> или IEnumerable<string>, как можно было ожидать.

Чистая придирка. Проблем в возвращении массива нет никаких. А так как массивы реализуют описанные тобой интерфейсы, то ты можешь такие методы рассматривать и как возвращающие интерфейсы. В общем, никаких проблем тут нет. Массив вполне логичный контейрен и его возврат совершенно корректное решение.

AF>Для массивов возможна ко/контра-вариантность элементов, для остальных коллекций – нет.

Согласен. Не красиво. Темболее, что для интефрейсов это возможно. Могли бы в Шарпе хотя бы это реализовать.

AF> Массивы можно инициализировать списком значений в коде, для коллекций это невозможно.

Приминительно к CLI это утверждение не верно. Инициализация — это фишка ЯП. Так что это притензия к Шарпу. И в версии 3.0 она похоже будет исправлена.

AF>Большинство коллекций поддерживают возможность добавлять элементы без пересоздания объекта, для массивов эта возможность недоступна. Для большинства коллекций доступен метод AsReadOnly() или аналог, для массивов такой возможности нет.

Это вообще заблуждение:

using System;
using System.Collections.Generic;

class Program
{
    public static readonly int x = 1;

    static void Main()
    {
        int[] ary = new int[] { 1, 2, 3 };
        IList<int> lst = Array.AsReadOnly(ary);
        lst[0] = 123;
    }
}

AF>Генерики
AF>Много лишней писанины, если нужно создать систему из нескольких связанных типов, имеющих общие параметры.

Не понял претензии. Но подозреваю, что она поять же не к дотнету или КЛИ, а к Шарпу.

AF>Нельзя использовать Enum в качестве констрэйнта на тип.

Это тоже проблема C#. Например, в Nemerle таких ограничений нет.

Подытоживая... как минимум неверно названа тема. Перечисленные тобой претензии в основном относятся к C#.

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

AF>Все равно я думаю, что escape-анализ — это самый правильный путь. Пусть и более сложный в реализации.

Ради справедливости надо заметить, что тогда по уму нужно отказываться вообще от вэлью-типов. Это снимет море проблем. Но оптимизатр при этом должен будет быть просто зверским. Иначе будет ну очень не быстро и расточительно по памяти.

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

kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта операция не согласуется с идеологией безопасных языков.

Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.

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

AF>

AF>class Test: ICloneable
AF>{
AF>  public Test Clone() // а вот хрен то там!
AF>    {
AF>    ...
AF>    }
AF>}
AF>

AF>Так что вместо простого и понятного кода придется воротить два метода и явную реализацию метода интерфейса, менее понятно и более громоздко. И это еще самый тривиальный пример.

interface ICloneable<T>
{
    T Clone();
}

class Test : ICloneable<Test>
{
  public Test Clone() // OK
    {
    ...
    }
}

WH>>Дело в том что есть объекты которые должны быть изменяемыми и есть объекты которые должны быть не изменяемыми.

AF>Чушь.
AF>

AF>// made by Vasya
AF>class Document : IDisposable
AF>{
AF>....
AF>}

AF>// made by Petya
AF>static class Printer
AF>{
AF>  public static Print(Document doc)
AF>    {
AF>      ...
AF>        doc.Dispose(); // опа!
AF>    }
AF>}
AF>

AF>Ну так что, документ он какой — изменяемый или неизменямый?

Ты что тут пытался то продемонстрировать?

AF>>>Нет кортежей.
WH>>Легко эмулируются при помощи генериков.

AF>а ты пробовал?

Ну, вон в Немерле так и сделано.

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

WH>А как насчет сильной связанности?

Смотря как применять.

WH>А может нужно просто подругому подходить к проектированию? Вот у меня почемуто таких проблем не возникает.
WH>К тому же это можно решить на уровне конкретного языка. Или вобще метапрограммированием.

Проблем у меня тоже не возникает. Но лишняя писанина напрягает.

WH>Пробовал. Получилось при помощи одного генерик класса и одного класса заглушки. С их помощью можно генерировать кортежи произвольной длинны. Если у тебя не хватает фантазии то это не мои проблемы.

опять метапрограммирование?

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

ну зачем такой страшный оверквотинг?

AF>>Ну так что, документ он какой — изменяемый или неизменямый?

VD>Ты что тут пытался то продемонстрировать?

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

VD>Ну, вон в Немерле так и сделано.

Ок, этот пункт убираю.

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

AF>>Большинство коллекций поддерживают возможность добавлять элементы без пересоздания объекта, для массивов эта возможность недоступна. Для большинства коллекций доступен метод AsReadOnly() или аналог, для массивов такой возможности нет.

VD>Это вообще заблуждение:

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

VD>Не понял претензии. Но подозреваю, что она поять же не к дотнету или КЛИ, а к Шарпу.

Возможно...

VladD2 wrote:

> kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта
> операция не согласуется с идеологией безопасных языков.
> Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.
А в каком языке есть const, но нет const_cast?

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

VD>Ради справедливости надо заметить, что тогда по уму нужно отказываться вообще от вэлью-типов. Это снимет море проблем.
Каких проблем?

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

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

>> Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.
kan>А в каком языке есть const, но нет const_cast?
Ты лучше покажи язык кроме С++ где этот самый const_cast есть...

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

kan>VladD2 wrote:

>> kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта
>> операция не согласуется с идеологией безопасных языков.
>> Вот за const_cast нужно бить морду. Причем сильно, длого и прилюдно.
kan>А в каком языке есть const, но нет const_cast?

В большинстве функциональных, правда неявный

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

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

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

AF>Нет возможности использовать константные ссылки на объекты

WH>Дело в том что есть объекты которые должны быть изменяемыми и есть объекты которые должны быть не изменяемыми. Есть объекты которые должны передоваться по ссылке и есть объекты которые должны передоватся по значению.
WH>Это не вопрос оптимизации это вопрос архитектуры. Нельзя мешать теплое с мягким. Ничего хорошего из этого не выходит.

о, кстати этот вопрос я тоже пока не догнал, можно поподробнее — есть ссылочный тип, есть метод, в который он передается в качестве параметра и который его изменять не должен, только читать — как это разруливается в C#?

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

OE>о, кстати этот вопрос я тоже пока не догнал, можно поподробнее — есть ссылочный тип, есть метод, в который он передается в качестве параметра и который его изменять не должен, только читать — как это разруливается в C#?

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

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

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

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

V>С точки зрения шарпа, тут косяк в архитектуре, так как по сути передаваемый объект имеет открытые методы и свойства, доступ к которым должен быть закрыт. То есть надо было передавать не объект целиком, а, лишь, некоторый тоненький интерфейс, через который можно делать только то, что разрешено явно. Хорошо это, или плохо — это другой вопрос. Я вот не знаю, хорош этот подход, или, наоборот плох. Хотелось бы услышать соображения общественности
На мой взгляд здесь сколько не косяк, а именно недоработочка. Если бы у типа был некоторый модификатор который запрещал бы менять внутреннее состояние объекта кроме как в конструкторе, IMHO, это было бы правильнее и проще.

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

GZ>На мой взгляд здесь сколько не косяк, а именно недоработочка. Если бы у типа был некоторый модификатор который запрещал бы менять внутреннее состояние объекта кроме как в конструкторе, IMHO, это было бы правильнее и проще.
И я о том же. Должны быть изменяемые и не изменяемые объекты.
А где-то изменяемый и где-то не изменяемый объект это прямой путь на минное поле.