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

ZORK>Если у кого что-нить есть по subj., или просто есть желание пообсуждать — ПИШИТЕ

Ну давай, побалякаем :)

ZORK>Интересуют ссылки на ресурсы, где рассматриваются Generic Types и их необходимость. Особено интересно понять как это соотносится с ОО-программированием: дополняет, отменяет :) или то же самое но другими словами.

Давай сразу отделим: мухи отдельно, котлеты отдельно. Generic Types лишь часть шаблонов и шаблоны более широкое понятие, в том числе и реализующее ОО концепцию полиморфизма, что прекрасно демонстрируется библиотеками stl и ATL.

ZORK>Насколько я сам сейчас понимаю: Generic Types это хороший способ писать некий мета-код, который в процессе компиляции генерерирет код с конкретным типом, который в свою очередь позволяет выполнить оптимизиацию кода на стадии компиляции.

Точно, в самую дырочку.

ZORK>Но вроде как, та же универсальность может быть достигнута имея универсальный тип Object и возможость получить от переменной этого типа конкретный интерфейс. Так что основным аргументом является то, что так заведомо медленно, а если с Generic Types то компиляторы могут хорошо оптимизировать.

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

Ещё один аргумент — отсутствие проверки совместимости типов на стадии компиляции. Честно скажу, я задолбался с вариантами в javascript и наелся универсальности и полиморфности типов по самые помидоры. Больше не хочу, хочу нормальной проверки типов на стадии компиляции. Универсальные типы — ЗЛО! Елементарный алгоритм быстрой сортировки многократно усложняется при использовании универсальных питов. Я делю целое на целое, а получаю плавающее 8( За что? :)

ZORK>По сути, у меня все свелось к двум вопросам:

ZORK>- есть ли какое-нить, хотя бы империческое, доказательство того что нельзя построить компилятор, который будет делать то же что и generic types, просто основываясь на коде, в котором используется тип Object и тех интерфейсах к которому переменный типа Оbject приводят

Я сомневаюсь. Можно сделать компилятор с прогнозированием, основанным на коде. Но, если ты пишешь библиотечную функцию или метод объекта... какой тип будет у входного параметра? Nobody knows. Точнее, знает только программист, который будет использовать твою функцию/объект. Ответсвенность за правильное понимание входных параметров лежит на тебе. И что ты будешь делать, если ты ожидаешь строку, ну в крайняк целое, а тебе приходит массив дат?

ZORK>- не являются ли generic types средством решения изночальной кривизны, возможно неизбежной, заложенной в языки программирования (C++, Java, С#): наличие примитивных типов (int, long, String и т.д.) и не примитивных типов, у которых есть интерефейсы и прочие, что не позволяет написать эффективно написать код, который мог бы работать одновременно с переменный из обоих этих групп. Так что, бы интересно узнать про какую-нить теорию насчет примитивных типов, и их необходимости.

Я вижу только одну проблему с преобразованием типов в C++ — ambiguous. Это задалбывает, и здесь универсальные типы, которые имеют откровенные приоритеты при преобразовании, сильно упрощают код. Если бы в C++ был механизм задания приоритетов преобразования типов, то это позволило бы решить многие проблемы.

Я не против универсальных типов, я против подмены ими строгости типизации. Если тип документированно преобразуем к другому типу или группе типов на стадии компиляции — пусть живёт, если нет нафинг, лишняя строчка кода не усложнит читабельность программы, но позволит избежать многих проблем при разработке и сопровождении кода.