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

Tom>Да в общем вариантов куча. Можно на основе массивов. Только опять же зачем это делать. Думаю сравнив производительность большого выигрыша не получится.

А ты не думай, а сравни. Если возьмешь ArrayList, но на вылью-типах получишь такой провал производительности, что самому противно статент. Мы тут с AVK, как то на эту тему беседовали. Я ему приводил примерчик. Назница на парядки.

Если же сделаешь на типизированных массивах, то для каждого типа элемента придется писать свой динмический массив и свой варинт коллекции. Собственно от этого и избавляют шаблоны.

Короче, если что-то кажется непонятныи и пугающим, не нужно сразу на него ставить "ярлык". Лучше сначала разобраться и попробывать.

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

VD>Ерунду ты говоришь. Все же прежде чем судить о чем-то нужно это что-то как следует попробывать.


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

VD> Покажи хотя-бы один класс который ты написал на шблонах.

В смысле на плюсовых? Вряд ли найду, давно это было.

Tom>>PS: Помидорами не кидать. Основываюсь на своём опыте разработки и применении шаблонов.

VD>Странный у тебя опыт.


Опыт суппорта продуктов в десятки мегабайт кода. В которых НЕВОЗМОЖНО в принципе разобраться что к чему из за обилия шаблонов и стиля их написания. К примеру попробуй полностью разобраться как реализован у M$ STL. А если на них ещё навёрнуто 5-6 слоёв то как ??? Возникает ОЧЕНЬ много вопросов. Если бы использовались интерфейсы, то решения были бы на много прозрачнее. Хотя это вопрос вкусов, о которых как известно.... Но мо странный опыт суппорта говорит, что это очень плохое решение.

VD>Короче, если что-то кажется непонятныи и пугающим, не нужно сразу на него ставить "ярлык". Лучше сначала разобраться и попробывать.

Я и не ставлю. Просто выигрывая в одном проигрываешь в другом. Выигрывая во времени написания проекта проигрываешь во времени отладки и суппорта.

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

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

M>>>Сейчас нет готового метода сделать хорошую collection для типов ValueType. Всё время лезет boxing/unboxing. Это обсуждается как раз в другой ветке.
Tom>>Ну это ты соврал конечно. Можно и без проблемм.

VD>Пример в студию! И оцени объем кода.

VD>

Достали в общем. Пошол писать. Буду недели через 2. Спорим на пиво, что не уступлю более чесм 30%.

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

Tom>Достали в общем. Пошол писать. Буду недели через 2. Спорим на пиво, что не уступлю более чесм 30%.

Ну давай пить пиво.

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

Tom>Я и не ставлю. Просто выигрывая в одном проигрываешь в другом. Выигрывая во времени написания проекта проигрываешь во времени отладки и суппорта.

Генерики способны только ускорить разработку (так как не нужно писать лишний код). И упростить отладку (так как типобезопастность повышается).

Пойми, это просто возможность записать алгоритм абстрагируясть от конкретных типов данных. Ведь без них ты или вынужден писть отдельные реализации для каждого типа. Или делать все полиморфным. Ну спервым понятно. И отладка, и поддержка, и поре кода... Ну а полиморфный подход дает длве проблемы. Неоптимальную производительность (особенно с вэлью-типами, из-за боксинка). И отсуствие типобезопастности. Минусов нет. Вы их придумываете.

А в других местах их применять не нужно. Тогда и проблем не будет.

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

Tom>Опыт суппорта продуктов в десятки мегабайт кода. В которых НЕВОЗМОЖНО в принципе разобраться что к чему из за обилия шаблонов и стиля их написания.

Может дело в стиле их написания? Вот возьми к примеру ATL/WTL. Шаблонов море. Но разобраться в них раз плюнуть. Народ справляется даже без документации.

Tom>К примеру попробуй полностью разобраться как реализован у M$ STL.

Ну я в общем разбирался. Проблем особых нет. Только два замечания:
1. STL довольно кривая по дизайну библиотека.
2. МС к ней отношение имее очень отдаленная. Это скорее HP.

Tom>А если на них ещё навёрнуто 5-6 слоёв то как ???

Слышал про такое понятие — абстракция? Надеюсь, да. Так вот если абстракция хорошо продумана и воплощена шаблоном, то пользоваться ею очень прото и удобно. В то же время ту же абстракцию можно воплотить методом полиморфизма и получить очень плохой результат (то о чем ты говоришь). В общем, дело не в методе реализации абстракции, а в грамотности ее проработки.

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

Tom>Возникает ОЧЕНЬ много вопросов. Если бы использовались интерфейсы, то решения были бы на много прозрачнее.

А что? Шаблоны отменяют интерфейсы? Ты путаешь дотнет с комом. Это в коме нельзя было использовать шаблоны. В Шарпе это как раз будет возможно. К примеру вместо дурацкого IList, где все методы описаны через object. Будет IList<T>. Где T — это тип элемента. Причем IList<T> ничем ни в чем остальном (кроме типизированности) не будет отличаться от своего пропращура. Даже будет доспупен решлекшон.

Tom>Хотя это вопрос вкусов, о которых как известно.... Но мо странный опыт суппорта говорит, что это очень плохое решение.

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

PS
Учти в шарпе не будет многих проблем которые были в С++. И синтаксис шаблонов будет тоже проще.

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

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

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

Честно говоря макросы в умелых руках вещь мощьная. Н к сожелению проблем у них хватает. Вероятно можно придумать концепцию типизированных макросов, но это уже скорее всего будет развитием шаблонов.

AVK>В этом случае область применения шаблонов значительно расширилась бы.

Во-во. На маросах можно намного больше чем на шаблонах. Можно даже шаблоны эмулировать. Только радости от этого никакой.

AVK>Например можно было бы реализовать весь стандартный набор паттернов ввиде таких шаблонов.

Их и в виде обычных классав (ну максимум с шаблонами) можно реализовать.

AVK>В смысле на плюсовых? Вряд ли найду, давно это было.

Оно и чувствуется. Я просто уверен, что после того как в Шарпе появятся шаблоны ты будеш одним из первых их поклонников. Помяни мое слово. Мы создавая С++-код в конце концов 80% стали делать на шаблонах. Так как это и шустрее и проще.

Ну а если Шаблоны решат проблему подключения реализации к интерфейсам, то им вообще цены не будет.

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

VD>Все же по твоим словм сразу видно, что опыт работы на плюсах у тебя очень маленький.

Давай не будем здесь обсуждать мой опыт работы на плюсах? ОК?

VD> То что ты предлагаешь давно было еще в старом добром С (без плюсов). Назывлось макросами.

Ничего похожего. Рекомендую поглядеть на тугезу и посмотреть как там реализованы паттерны. Вот хотелось бы поддержку подобного со стороны языка чтобы не приходилось городить 2-way tools.

VD>Их и в виде обычных классав (ну максимум с шаблонами) можно реализовать.

Эффективно, да еще с типизацией, нельзя. Потому как параметрами паттернов могут быть не только типы.

VD>Оно и чувствуется. Я просто уверен, что после того как в Шарпе появятся шаблоны ты будеш одним из первых их поклонников. Помяни мое слово. Мы создавая С++-код в конце концов 80% стали делать на шаблонах. Так как это и шустрее и проще.

Я где то писал что мне шаблоны не нравятся и так не шустрее и не проще?

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

VD>>Все же по твоим словм сразу видно, что опыт работы на плюсах у тебя очень маленький.
AVK>Давай не будем здесь обсуждать мой опыт работы на плюсах? ОК?

Правильно. Будем обсуждать вкус устриц с теми кто их не пробывал.

VD>> То что ты предлагаешь давно было еще в старом добром С (без плюсов). Назывлось макросами.

AVK>Ничего похожего. Рекомендую поглядеть на тугезу и посмотреть как там реализованы паттерны. Вот хотелось бы поддержку подобного со стороны языка чтобы не приходилось городить 2-way tools.

Ты описал макросы (практически точное определение дал).

VD>>Их и в виде обычных классав (ну максимум с шаблонами) можно реализовать.
AVK>Эффективно, да еще с типизацией, нельзя. Потому как параметрами паттернов могут быть не только типы.

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

VD>>Оно и чувствуется. Я просто уверен, что после того как в Шарпе появятся шаблоны ты будеш одним из первых их поклонников. Помяни мое слово. Мы создавая С++-код в конце концов 80% стали делать на шаблонах. Так как это и шустрее и проще.

AVK>Я где то писал что мне шаблоны не нравятся и так не шустрее и не проще?

А то? Вот (двумя ветками выше):

Tom>>Вопрос как мне кажется не в том будут ли шаблоны, а в том нужны ли они. На мой взгляд шаблоны — ошибочная ветка развития ООП и в .NET не нужны. Абсолютно любую задачу, рещаемую при помощи шаблонов можно решить более красиво и более просто.

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

Твои слова? Из них однозначный вывод, что если кроме скорости кода шалоны ничего не дают.

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

VD>Я еще раз повторяю... ты просто никогда не использовал шаблонов и не понимаешь всей их гибкости. Через параметры можно передавать как просто типы данных, так и логику. В конце коныов любой класс может содержать логику.

А что средствами ООП не получится, даже паттерн специальный есть, только вот забыл как он называеься.

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

AVK>>Ничего похожего. Рекомендую поглядеть на тугезу и посмотреть как там реализованы паттерны. Вот хотелось бы поддержку подобного со стороны языка чтобы не приходилось городить 2-way tools.

VD>Ты описал макросы (практически точное определение дал).

Нет, макросы это слишком примитивно.

VD>Я еще раз повторяю... ты просто никогда не использовал шаблонов и не понимаешь всей их гибкости. Через параметры можно передавать как просто типы данных, так и логику. В конце коныов любой класс может содержать логику.

Если тащить эту логику в отдельном классе то весь кайф шаблонов пропадает.

AVK>>Я где то писал что мне шаблоны не нравятся и так не шустрее и не проще?

VD>А то? Вот (двумя ветками выше):

Вот и приведи цитату. Я всего лишь сказал что шаблоны можно было бы сделать погибче. Но это не значит что шаблоны в теперешнем виде не нужны. Ты как всегда начинаешь читать между строк.

AVK>>Просто имхо шаблоны не очень гибкая вещь, варианты параметров весьма ограничены. Я бы предпочел встроенную в код полномасштабную поддержку кодогенерации а не затычки ввиде шаблонов.

VD>Твои слова? Из них однозначный вывод, что если кроме скорости кода шалоны ничего не дают.

По сравнению с полиморфизмом и рефлекшеном? Да, практически ничего. Все остальные их фичи без проблем реализуются.

VD>2. МС к ней отношение имее очень отдаленная. Это скорее HP.

Пусть будет HP. Не всегда же камни кидать в M$ сторону

Tom>>А если на них ещё навёрнуто 5-6 слоёв то как ???

VD>Слышал про такое понятие — абстракция? Надеюсь, да.
Неа. А это что такое ?

VD>Так вот если абстракция хорошо продумана и воплощена шаблоном, то пользоваться ею очень прото и удобно.

В общем давай разбираться про какие абстракции мы говорим. Возьмём твой пример с IList<T>, только переименуем в Foo. Да действительно в данном случае не плохо будет если параметром можно будет пихать тип хранимых данных. Но если шаблон будет типа Foo<Class T> это будет означать явную зависимость класса от интерфейса класса, передаваемого в качестве параметра. Т.е что бы передать класс в качестве парамемтра, я буду должен реализовать набор определённых, пусть и не виртуальных, методов, что называется интерфейс. Замечаешь ключевое слово Эту же задачу я мог бы решить следующим образом.

1. Обьявить интерфейс.
2. В классе Foo сделать свойство или метод, принимающий необходимый интерфейс.
3. Реализовать данный интерфейс и передать классу Foo

Итак какие мы получаем выгоды. Прозрачность кода, так как интерфейс описан и связывание происходит в рантайм. Недостатки — так как связывание идёт в рантайм то ухудшается производительностью. Насколько этот недостаток критичен — это вопрос конкретной задачи.

Выводы
На данном этапе я для себя уяснил, что: простой тип, структура, Value Class в качестве параметра шаблона — хорошо, так как шаблон улучшает алгоритм, делая его не зависимым от типа используемых данных. Хотя на самом деле наверное хорошо — это только простой тип, так как и структура и Value Class вносит зависимость от интеорфейса в большинстве случаев. Класс с определённой функциональностью — плохо, так как вносит зависимость от интерфейса, явно не определяя этого интерфейса, что приводит к осложненим при отладке.


Я не знаю, что нового собирается M$ привнести в шаблоны, но будем надеятся что это как сказал Влад только улучшит перфоманс и простоту суппорта и отладки, чего не было с старых шаблонах.

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

Tom>В общем давай разбираться про какие абстракции мы говорим. Возьмём твой пример с IList<T>, только переименуем в Foo. Да действительно в данном случае не плохо будет если параметром можно будет пихать тип хранимых данных. Но если шаблон будет типа Foo<Class T> это будет означать явную зависимость класса от интерфейса класса, передаваемого в качестве параметра.

Это без разницы будет там слово class или нет. А то что шаблон будет строиться на базе интерфейса типа данных T — это большое приимущетсво, так как все проверки можно будет сделать дизайнтайме. И тебе просто не дадут скомпилировать Foo<Some> если Some не поддерживает нужной для Foo функциональности.

Т.е что бы передать класс в качестве парамемтра, я буду должен реализовать набор определённых, пусть и не виртуальных, методов, что называется интерфейс. Замечаешь ключевое слово Эту же задачу я мог бы решить следующим образом.

Tom>1. Обьявить интерфейс.
Tom>2. В классе Foo сделать свойство или метод, принимающий необходимый интерфейс.
Tom>3. Реализовать данный интерфейс и передать классу Foo

Нет не сможешь. Нано или поздно ты скатишся на поля/параметры типа object и как следствие потерю производительности и проблемы с контролем типов (который придется выполнять в рантайме и вручную).

Tom>Итак какие мы получаем выгоды. Прозрачность кода, так как интерфейс описан и связывание происходит в рантайм. Недостатки — так как связывание идёт в рантайм то ухудшается производительностью. Насколько этот недостаток критичен — это вопрос конкретной задачи.

Ну выводы сделанные на неверных предпосылках...

Так что лучше не надо философии вот тебе обратно обычный IList и его индексатор:

object this[int index] {get; set;}

С шаблонами его можно будет описать так:

interface IList<T>
{
  ...
  T this[int index] {get; set;}
  ...
};

Попробуй использовать свой интерфейс.

Tom>Выводы
Tom>На данном этапе я для себя уяснил, что: простой тип, структура, Value Class в качестве параметра шаблона — хорошо, так как шаблон улучшает алгоритм, делая его не зависимым от типа используемых данных. Хотя на самом деле наверное хорошо — это только простой тип, так как и структура и Value Class вносит зависимость от интеорфейса в большинстве случаев.

Глупость. Зависимость от интерфейса будет всегда. Действи типа "=", "==", "+" и т.п. — это тоже интерфейс. Весь кайф шаблонов, в том что ты можешь пользоваться им наиболее эффективно и не прибегать к полиморфизму. Более того шаблоны дают некий упрощенных статический полиморфизм, который намного более безопасен и эффективен.

Tom>Класс с определённой функциональностью — плохо, так как вносит зависимость от интерфейса, явно не определяя этого интерфейса, что приводит к осложненим при отладке.

Полнейшая ерунда. Никаких осложнений при отладке нет. Это проверено тем же С++. На заре С++ были проблемы с отладчиками, но сегодня таких проблем нет и шалблоны прекрасно отлаживаются.

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

class Foo<T>
{
  IBar<T> bar;
};

Tom>Я не знаю, что нового собирается M$ привнести в шаблоны, но будем надеятся что это как сказал Влад только улучшит перфоманс и простоту суппорта и отладки, чего не было с старых шаблонах.

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

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

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

AVK>Нет, макросы это слишком примитивно.

Эта та самая кодогенерация при компиляции о которой ты говорил. Причем на макросах действительно можно очень многое. При грамотном использовании они позволяют превратить ужасные конструкции в простые и понятные абстракции (типа мапов из АТЛ). Но вот в руках новичков — это страшно.

AVK>Если тащить эту логику в отдельном классе то весь кайф шаблонов пропадает.

Наоборот усиливается. Вот пример:

MyArray<T, Comparer>
{
  ...
  Sotr(...)
  {
    ...
    // Сравниваем значения
    if(Comparer.Equal(this[x], this[y])
      ...
    else
      ...
    ...
  }
};

Далее можно создать несколько реализация Comparer-а эффктивно сравнивающих элементы разных типов. Более того можно создать Comparer который осуществляет разные алгоритмы сравнения и использовать нуждый в определенных местах.

Конечно можно можн все тоже самое сделать на полиморфизме (интерфейсах или делегатах принемающих в качестве параметра object-ы), но это приведет к сильному подению производительности и трудно уловимым рантайм ошибкам.

AVK>Вот и приведи цитату. Я всего лишь сказал что шаблоны можно было бы сделать погибче. Но это не значит что шаблоны в теперешнем виде не нужны. Ты как всегда начинаешь читать между строк.



Тебе нельзя привести цитату если ты уже понял, что был не првл.

AVK>По сравнению с полиморфизмом и рефлекшеном? Да, практически ничего. Все остальные их фичи без проблем реализуются.

Трепачь находка для шпиенов. Если все легко реализовалось, то МС с шаблонами бы и не дергалось. В общем спорить с тобей безсмысленно. Вот появятся шаблоны посмотрим как ты без них будет обходиться. Уверяю теб что ты первый будешь их использовать и проблема производительности будет далеко не на первом месте.

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

K>А что средствами ООП не получится, даже паттерн специальный есть, только вот забыл как он называеься.

Можно то оно можно. Но ты зароешься в приведениях типов и рантйме. С шаблонами все проще.

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

Одна типобезопастность уже неоспоримое достоинство. В С++ с помощью шаблонов и переопределения операторов народ творит чудеса. Надеюсь в Шарпе будет также.

PS

Заметьте. Среди людей наезжающих на шаблоны (ну или пытающихся свести их достоинства только к увеличению производительности) все не имели большого опыта работы с шаблонами. А все кто успешно использовал шаблоны в С++ ждут их пояления в Шарпе. Это явно не спроста.

Маленькое введение. Прошу в дальнейшем не высказываться с позиции безапиляционно правого. Это конечно хорошо, что ты опытен во многих вещах, но мы ведём дискуссию, а не лекцию

VD>Это без разницы будет там слово class или нет. А то что шаблон будет строиться на базе интерфейса типа данных T — это большое приимущетсво, так как все проверки можно будет сделать дизайнтайме. И тебе просто не дадут скомпилировать Foo<Some> если Some не поддерживает нужной для Foo функциональности.
И кто сказал, что это хорошо. Это вообще тема для отдельной бисседы и изучения. Вон в коме всё в рантайм и работает прекрасно. Никаких проблемм с контролем типов. И проблемм меньше, так как модули изолированны и работа идёт только при помощи интерфейсов.

VD>Нет не сможешь. Нано или поздно ты скатишся на поля/параметры типа object и как следствие потерю производительности и проблемы с контролем типов (который придется выполнять в рантайме и вручную).
Пойми одну простую вещь. Я разделяю для себя 2 случая. 1 — когда параметром шаблона является простой тип. 2 — когда класс или интерфейс (не шаблонный). Так вот в 1 случае шаблоны хорошо (док. см. в предыдущем посте), а во втором — плохо. По поводу производительности — это то же отдельный разговор.

Tom>>Итак какие мы получаем выгоды. Прозрачность кода, так как интерфейс описан и связывание происходит в рантайм. Недостатки — так как связывание идёт в рантайм то ухудшается производительностью. Насколько этот недостаток критичен — это вопрос конкретной задачи.

VD>Ну выводы сделанные на неверных предпосылках...
Ну ну. Зайди ка в форус по C++ и посмотри какие у народа проблеммы и с чем... Кстате посмотрим на этот форум после введения этих шаблонов.

VD>Так что лучше не надо философии вот тебе обратно обычный IList и его индексатор:
VD>

VD>object this[int index] {get; set;}
VD>

VD>С шаблонами его можно будет описать так:
VD>

VD>interface IList<T>
VD>{
VD>  ...
VD>  T this[int index] {get; set;}
VD>  ...
VD>};
VD>

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

Tom>>Выводы
Tom>>На данном этапе я для себя уяснил, что: простой тип, структура, Value Class в качестве параметра шаблона — хорошо, так как шаблон улучшает алгоритм, делая его не зависимым от типа используемых данных. Хотя на самом деле наверное хорошо — это только простой тип, так как и структура и Value Class вносит зависимость от интеорфейса в большинстве случаев.

VD>Глупость. Зависимость от интерфейса будет всегда. Действи типа "=", "==", "+" и т.п. — это тоже интерфейс. Весь кайф шаблонов, в том что ты можешь пользоваться им наиболее эффективно и не прибегать к полиморфизму. Более того шаблоны дают некий упрощенных статический полиморфизм, который намного более безопасен и эффективен.
Про "=", "==", "+" — полностью с тобой согласен и очень жалею, что перегрузка операторов есть в .NET. В Java её нет и никто об этом не парится, кроме любителей C++. По поводу шаблонов — никакого понимаешь упращения. Единственный плюс — независимость алгоритма от типа данных.

Tom>>Класс с определённой функциональностью — плохо, так как вносит зависимость от интерфейса, явно не определяя этого интерфейса, что приводит к осложненим при отладке.

VD>Полнейшая ерунда.
VD>Никаких осложнений при отладке нет. Это проверено тем же С++. На заре С++ были проблемы с отладчиками, но сегодня таких проблем нет и шалблоны прекрасно отлаживаются.
Проверено на C++ что проблемм куча. Как ты думаешь сколько примерно займёт на экране 800*600 сообщение об ошибке выданное gcc на какую нибудь ошибку в классе map<string, string>. Пол экрана идёт только перечисление класса.


ЗЫ: В принципе если шаблоны упростят и так как нет множественного наследования, то не всё так плохо

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

AVK>... Интерфейс это максимально абстрагированный интерфейс доступа к чему либо. ...
Непробовал толковые словари писать? У тя определенно талант.
Твое определение интерфейса просто супер — "интерфейс — это интерфейс"!
Емко... Внушает...

V>>Я бы сказал, что это операция композиции интерфейсов.

AVK>Ну поспорь с документацией
AVK>ms-help://MS.NETFrameworkSDK/csspec/html/vclrfcsharpspec_13_1_2.htm
AVK>

AVK>An interface can inherit from zero or more interfaces, which are called the explicit base interfaces of the interface
AVK>

AVK>Если по твоему inherit переводится как композиция то тогда конечно.

V>>Наследование несет определенную смысловую нагрузку, связянную с
V>>приобретением данных/кода предка.

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

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

AVK>>>Они много для чего нужны. Не только для этого.

V>>Да, все это полезные дополнения.

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

Интерфейс это всего лишь навсего некоторый зафиксированный протокол сообщений. Если мы, скажем, ограничим этот протокол одним методом, то, в принципе, с технической точки зрения мы ничего не потеряем. А это уже очень напоминает, хм... делегата. И далее простой подстановкой интерфейс->делегат мы можем сохранить все возможности.
Как ты выразился интерфейс это маска, надеваемая на объект. Все остальное — его удачное применения.
Первоначальное назначение интерфейса — поддержка полиморфизма вне дерева наследования. Правда у COM нет никакого дерева, там все грубо говоря Object, но назначение такое же — представление одного объекта в разных ролях.

--

Владимир.