недостатки системы типов .NET - Философия программирования

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

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

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

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

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

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

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

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

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

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

Коллекции
Одновременное применение в системе типов .NET массивов, нетипизированных коллекций, специализированных коллекций и генерик-коллекций, которые все «немного похожи» и «немного разные». Соответственно, методы из FCL возвращают разные типы — это создает лишнюю путаницу и сложности при программировании.
Например, String.Split возвращает string[], а не IList<string> или IEnumerable<string>, как можно было ожидать.
Для массивов возможна ко/контра-вариантность элементов, для остальных коллекций – нет. Массивы можно инициализировать списком значений в коде, для коллекций это невозможно.
Большинство коллекций поддерживают возможность добавлять элементы без пересоздания объекта, для массивов эта возможность недоступна. Для большинства коллекций доступен метод AsReadOnly() или аналог, для массивов такой возможности нет.
Генерики
Много лишней писанины, если нужно создать систему из нескольких связанных типов, имеющих общие параметры.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Пардон, ссылка кривая. Правильный адрес — здесь

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AF>Впрочем, это только мое мнение — на абсолютную правоту я не претендую

И это правильно.

AF>Если у кого-то есть желание расширить список — welcome.
нет. Но поправить — можно. Прежде всего — CLI это не пользовательский язык программирования а все-го лишь основа для расширения с помощью более высоких языков программирования. И именно с этой точки зрения нужно подходить.

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

AF>Нет ковариантности для переопределения виртуальных методов.
+1. Только если бы ковариантность была, то это создало бы более существенные проблемы для языков которые не поддерживают ковариантность. С другой стороны, ковариантность для пользовательских языков можно создать.

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

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

AF>Нет кортежей.
А кто мешает их сделать в пользовательском языке?

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

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

AF>Коллекции
AF>Например, String.Split возвращает string[], а не IList<string> или IEnumerable<string>, как можно было ожидать.
IList — это несколько другая опера, а IEnumerable<string> можешь легко получить из string[].

И к тому же обращение к объекту string[] несколько быстрее работает чем IEnumerable<string>.
AF>Для массивов возможна ко/контра-вариантность элементов, для остальных коллекций – нет. Массивы можно инициализировать списком значений в коде, для коллекций это невозможно.
AF>Большинство коллекций поддерживают возможность добавлять элементы без пересоздания объекта, для массивов эта возможность недоступна. Для большинства коллекций доступен метод AsReadOnly() или аналог, для массивов такой возможности нет.
Не забывай что коллекции чаще всего это те же массивы но обросшие мясом(то бишь методами).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

В CLI то вроде как раз можно.

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Это особенности конкретных языков, связанные с проблемами в синтаксисе. Сам CLR такую перегрузку поддерживает.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

GZ>Это не есть верно. Попробуй словить OutOfMemoryException и ExecutionEngineException вышеуказанным способом. Вряд ли это получится.

Если не ошибаюсь, это только во второй версии фреймворка добавили повторный выброс системных исключений из блоков catch. ИМХО, это явный костыль.

GZ>-1. Жабе пришлось пройти нехилый путь, чтобы сделать хоть как нибудь оптимизатор.

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

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

Проблема в том, что число сущностей умножено сверх всякой необходимости.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Как, впрочем, и ThreadAbortException

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

GZ>>Это не есть верно. Попробуй словить OutOfMemoryException и ExecutionEngineException вышеуказанным способом. Вряд ли это получится.

AF>Если не ошибаюсь, это только во второй версии фреймворка добавили повторный выброс системных исключений из блоков catch. ИМХО, это явный костыль.

Нет, соль в том, что ты некоторые исключения catch'ем не отловишь. Ибо поздно пить боржоми...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

ANS>В CLI то вроде как раз можно.
Точно. Слишком быстро прочитал. Это не CLS совместимо, но возможно. Посыпаю голову пеплом.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

V>Как, впрочем, и ThreadAbortException

Это еще почему??? ThreadAbortException спокойно ловится. У него просто есть свои причуды (после прохода по catch блоку он снова бросается).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

V>>Как, впрочем, и ThreadAbortException

GZ>Это еще почему??? ThreadAbortException спокойно ловится. У него просто есть свои причуды (после прохода по catch блоку он снова бросается).

Ну может и так...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

GZ>>Это не есть верно. Попробуй словить OutOfMemoryException и ExecutionEngineException вышеуказанным способом. Вряд ли это получится.

AF>Если не ошибаюсь, это только во второй версии фреймворка добавили повторный выброс системных исключений из блоков catch. ИМХО, это явный костыль.
Нет. Это не повторный выброс. Это фактически остановка приложения. Здесь ты еще забыл StackOverflowException.

GZ>>-1. Жабе пришлось пройти нехилый путь, чтобы сделать хоть как нибудь оптимизатор.
AF>Все равно я думаю, что escape-анализ — это самый правильный путь. Пусть и более сложный в реализации.
Нет. Это скорее ошибка. Повторюсь CLI — создавался как виртуальная машина для языков более высокого уровня. Байткод изначально предназначался для Java и получился как Java. Разделение на стек и память надо относить именно как плюс CLI, так как есть куча языков для которых такое разделение есть(например С++, С#) и нет(многие функциональные языки). Если его нет, то такой анализ(если он вообще для них нужен) должен проводится на уровне данного языка, и в терминах этого языка.

GZ>>Не забывай что коллекции чаще всего это те же массивы но обросшие мясом(то бишь методами).
AF>Проблема в том, что число сущностей умножено сверх всякой необходимости.
Я думаю нормально. Достаточно много примитивов чтобы пользоваться только ими. И самое главное, они весьма расширяемы чтобы строить свои коллекции.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

GZ>Нет. Это не повторный выброс. Это фактически остановка приложения. Здесь ты еще забыл StackOverflowException.

Если тупо сделать throw new ExecutionEngineException(), то ловится вполне благополучно. А если у них есть какой-то "специальный throw", то это, как и любые "особые случаи" — явный недочет в дизайне.

GZ>Нет. Это скорее ошибка. Повторюсь CLI — создавался как виртуальная машина для языков более высокого уровня. Байткод изначально предназначался для Java и получился как Java. Разделение на стек и память надо относить именно как плюс CLI, так как есть куча языков для которых такое разделение есть(например С++, С#) и нет(многие функциональные языки). Если его нет, то такой анализ(если он вообще для них нужен) должен проводится на уровне данного языка, и в терминах этого языка.

-1
Передача через стек — всего лишь способ оптимизации. А в С++ стековые значения все равно совсем не такие, как в CLI.

GZ>Я думаю нормально. Достаточно много примитивов чтобы пользоваться только ими.

слишком много

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

GlebZ wrote:

> AF>Нет возможности использовать константные ссылки на объекты, что
> вынуждает программиста создавать read-only версии объектов —
> дополнительная ручная работа.
> +1
Почему-то мне кажется, что const нельзя делать без const_cast, а эта операция не согласуется с идеологией безопасных языков.

Posted via RSDN NNTP Server 2.0

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

AF>Если тупо сделать throw new ExecutionEngineException(), то ловится вполне благополучно. А если у них есть какой-то "специальный throw", то это, как и любые "особые случаи" — явный недочет в дизайне.
Конечно у него другой throw.

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

GZ>>Нет. Это скорее ошибка. Повторюсь CLI — создавался как виртуальная машина для языков более высокого уровня. Байткод изначально предназначался для Java и получился как Java. Разделение на стек и память надо относить именно как плюс CLI, так как есть куча языков для которых такое разделение есть(например С++, С#) и нет(многие функциональные языки). Если его нет, то такой анализ(если он вообще для них нужен) должен проводится на уровне данного языка, и в терминах этого языка.
AF>-1
AF>Передача через стек — всего лишь способ оптимизации. А в С++ стековые значения все равно совсем не такие, как в CLI.
Абсолютно правильно.

Не все возможно запихать в стек. А если возможно то поведение сущности (например после процедуры box/unbox) несколько другое. И если предоставить эту информацию программисту чтобы он это учитывал, то система получится более эффективная чем набор эвристик. К тому же не всем языкам нужна именно модель памяти предоставленная Net. Кому-то достаточно и наиболее эффективно именно работа только в стеке(особенно это было бы заметно в форте), или наоборот в динамической памяти без стека(как было предложено в одной статье по функциональному программированию на этом сайте). Вобщем CLI — это инструмент. А модель памяти зависит от самого языка.

GZ>>Я думаю нормально. Достаточно много примитивов чтобы пользоваться только ими.
AF>слишком много
Кому как.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

kan>GlebZ wrote:

>> AF>Нет возможности использовать константные ссылки на объекты, что
>> вынуждает программиста создавать read-only версии объектов —
>> дополнительная ручная работа.
>> +1
kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта операция не согласуется с идеологией безопасных языков.
Нет. Не обязательно. Есть другой вопрос: зачем это делать на уровне CLI, и как передавать данный модификатор между сборками если вторая сборка скомпилена в языке который не поддерживает модификатор const. Вобщем const здесь не нужен.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

AF>Нет ковариантности для переопределения виртуальных методов.
Честно говоря не больно то оно и нужно. Особенно если не злоупотреблять наследованием.

Вот эти два пункта объеденю:
AF>Нет возможности использовать константные ссылки на объекты, что вынуждает программиста создавать read-only версии объектов — дополнительная ручная работа.
AF>Наличие типов, которые явно обозначаются как передаваемые через стек, и все связанные с этим усложнения системы типов (боксинг) и ограничения (нельзя наследовать от структур). На самом деле, решать, каким образом передавать объект в каждом конкретном случае – это задача оптимизатора.
Дело в том что есть объекты которые должны быть изменяемыми и есть объекты которые должны быть не изменяемыми. Есть объекты которые должны передоваться по ссылке и есть объекты которые должны передоватся по значению.
Это не вопрос оптимизации это вопрос архитектуры. Нельзя мешать теплое с мягким. Ничего хорошего из этого не выходит.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

GZ>Кому как.

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Метапрограммированием решается вообще всё — это не аргумент.

AF>>Нет ковариантности для переопределения виртуальных методов.
WH>Честно говоря не больно то оно и нужно. Особенно если не злоупотреблять наследованием.

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

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

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

Чушь.

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

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

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

GlebZ wrote:

>> > AF>Нет возможности использовать константные ссылки на объекты, что
>> > вынуждает программиста создавать read-only версии объектов —
>> > дополнительная ручная работа.
>> > +1
> kan>Почему-то мне кажется, что const нельзя делать без const_cast, а эта
> операция не согласуется с идеологией безопасных языков.
> Нет. Не обязательно.
Иначе им будет опасно пользоваться. А вдруг неправильно задизайнили либу и приходится изменять константы?

> Есть другой вопрос: зачем это делать на уровне CLI,
> и как передавать данный модификатор между сборками если вторая сборка
> скомпилена в языке который не поддерживает модификатор const. Вобщем
> const здесь не нужен.
Логично, если добавить const на уровень языка, просто как проверка времени компиляции, то ок.

Posted via RSDN NNTP Server 2.0

	От:	AndreiF
	Дата:	09.11.06 06:46
	Оценка:	9 (2) +2

	От:	AndreiF
	Дата:	09.11.06 06:50
	Оценка:

	От:	GlebZ
	Дата:	09.11.06 08:58
	Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	09.11.06 09:08
Оценка:	7 (1)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	09.11.06 09:12
Оценка:	+1