Как вы относитесь к паскалю? , (есть гипотеза)

Цитата applegame @ 15.02.14, 11:40

Существует еще как. Правда C++ решил их своим излюбленным методом - костылями.

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

Добавлено 15.02.14, 18:51
P.S. Заявить о вредности множественного наследования реализаций и объяснить его отсутствие в своём языке заботой о нас-таких-блин-бедных - это излюбленный троллинг горемык от маркетинга. Если нам не надо, мы просто не будем пользовать. А вот если надо, а его нет, тогда на помощь приходят костыли типа примесей, агрегатов с делегатами и прочими кротовыми норами, заполненными вакуумом с отрицательной плотностью энергии, лишь бы мы-такие-блин-бедные смогли-таки решить нашу задачу без мата в адрес маркетологов, и не дай бог эта задача не оказалась последней, решаемой нами-такими-блин-бедными на чудо-языке-всём-из-себя-удобном. И мало у кого мозги к этому времени не оказываются промытыми до такой степени, чтобы сообразить, что обычно задача диктует архитектуру, которую уже программист должен имеющимися средствами реализовать, а не наоборот - подгонять архитектуру под имеющиеся средства, лишь бы решить задачу.

Цитата Qraizer @ 15.02.14, 18:41

Добавлено 15.02.14, 18:51
P.S. Заявить о вредности множественного наследования реализаций и объяснить его отсутствие в своём языке заботой о нас-таких-блин-бедных - это излюбленный троллинг горемык от маркетинга. Если нам не надо, мы просто не будем пользовать.

+10000,
Эти самые маркетологи говорят множественное наследование плохо - потому что есть проблема
в том что один и тот же метод ,но с разной сигнатурой может оказаться в разных классах,
и код не скомпилируеться,
Да она есть, но в интерфейсах проблема точно такая же ,

sergioK, поправочка: это точно такая же проблема, если интерфейсы разные. Какая разница, из-за чего конфликт имён? Когда же они одинаковые, они просто являются одним и тем же интерфейсом.
Проблемы множественного наследования не существует. Это миф. Существует увеличенная сложность проектирования архитектур, сводящихся к множественному наследованию. Однако архитектура не станет проще, если исходно сводящуюся к множественным предкам задачу переархитектурить как-либо иначе, она станет только запутаннее, и существует большой риск решить в конечном итоге не ту задачу. Ага-ага, а потом мы убедим заказчика, что он именно эту хотел.

Цитата sergioK @ 15.02.14, 21:11

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

Нет, они, в основном, говорят, что множественное наследование плохо из-за проблемы ромба. А ее в интерфейсах нет.

Да ладно вам, узбагойдесь. Тема о паскакале

И часто разработчикам приходится сталкиваться с этим ромбом? Лично мне ни разу не захотелось так наследование организовать.

В любом случае, Qraizer прав. Это не проблема и не недостаток. Просто нужно принять то или иное решение. Возможно, что, например, в Eiffel(где ромб можно разруливать не только по классам, но и по полям, а так же решение принимается итоговым классом, а не промежуточными) это сделано лучше, чем в C++, не знаю, не использовал Eiffel на практике. Некоторые языки с множественным наследованием, такие как Питон и Scala(для trait'ов) просто линеаризуют иерархию. Возможно, это так же является более простым решением и лучшим компромиссом, чем у C++. Но вот именно для C++ подход с делением на обычное и виртуальное наследованием является самым органичным, поскольку соответствует принципу нулевой стоимости, не приводит к преждевременной пессимизации и позволяет управлять ситуацией как вздумается... Отказ же от множественного наследования привел бы к появлению интерфейсов и отдельного механизма миксинов/делегатов, что я плохо себе представляю в контексте остальных возможностей языка. Делегирование, кстати, в С++ рассматривали, но отказались в пользу множественного наследования...

Цитата D_KEY @ 16.02.14, 13:30

Делегирование, кстати, в С++ рассматривали, но отказались в пользу множественного наследования...

Что значит отказались ?
Что и кто мешает его применять, там где считаешь нужным разумееться ?

Цитата sergioK @ 16.02.14, 17:38

Цитата D_KEY @ 16.02.14, 13:30

Делегирование, кстати, в С++ рассматривали, но отказались в пользу множественного наследования...

Что значит отказались ?
Что и кто мешает его применять, там где считаешь нужным разумееться ?

Я имею в виду специальный языковой механизм делегирования, который когда-то предлагался:

class B {
    int b;
    void f();
};
 
class C : *p {
    B *p;
    int c;
};

void f(C *q)
{
    q->f(); // означает q->p->f()
}

Угу.

Цитата

...
Концепция выглядела многообещающей для представления структур, требующих большей гибкости, чем может дать обычное наследование. В частности, присваивание делегирующему указателю могло бы использоваться для изменения конфигурации объекта во время выполнения. Реализация была тривиальной, затраты - минимальными. Поэтому данную идею испытали несколько пользователей.
Много времени и сил здесь положил Билл Хопкинс (Bill Hopkins). К сожалению, все пользователи, применившие механизм делегирования, пострадали от серьезных ошибок и путаницы. Из-за этого возможность была исключена как из проекта, так и из Cfront версии 2.0.
Причины ошибок:

• функции в делегирующем классе не замещают функции в классе, которому операция делегируется;
• функция, которой передается управление, не может воспользоваться функциями из делегирующего класса или каким-то иным способом «вернуться» в делегирующий объект.

Ясно, что две эти проблемы взаимосвязаны. Разумеется, пользователи были предупреждены. Предостережения не помогли. Более того, я сам забыл собственные правила и попался в ловушку. Таким образом, проблему нельзя было назвать мелким огрехом, который исправляется с помощью обучения и предупреждений компилятора. В то время она казалась непреодолимой.
Сегодня мне кажется, что указанные проблемы имеют фундаментальный характер. Для решения первой потребовалось бы изменять таблицу виртуальных функций объекта, которому делегируется управление, если он связан с делегирующим объектом. Это плохо согласуется с языком в целом и с большим трудом поддается разумному определению. Кроме того, обнаружились примеры, когда мы хотели, чтобы два разных объекта делегировали управление одному и тому же «разделяемому» объекту. Нашлись и такие задачи, в которых нужно было делегировать управление через В* объекту производного класса D.
...

Сообщение отредактировано: Qraizer - 16.02.14, 18:43

Цитата Qraizer @ 16.02.14, 18:41

Цитата

Причины ошибок:

• функции в делегирующем классе не замещают функции в классе, которому операция делегируется;
• функция, которой передается управление, не может воспользоваться функциями из делегирующего класса или каким-то иным способом «вернуться» в делегирующий объект.

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

Это такие же «проблемы», как и проблема множественного наследования.

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

Добавлено 17.02.14, 12:29
P.S. Покажите на Дельфях код, который влёгкую меняет делегируемый объект в рантайм или разделяет его с кучей себе подобных.

Добавлено 17.02.14, 12:33
P.P.S. Ах да, ещё было бы интересно как Дельфи справится вот с этой задачей, на которую я уже ссылался в соседней теме. Напомню суть, чтоб много не читать. Там есть интерфейс, есть его готовая реализация, и есть расширение интерфейса. Хочется увидеть класс, реализующий новую версию интерфейса, но при этом пользующийся уже готовой реализацией его старой версии. Доп.условие: ни старый интерфейс, ни его реализация не курсе о новой версии вообще никак.

Добавлено 17.02.14, 12:37
P.P.P.S. Два доп.условия: наш класс при этом "является" реализацией старой версии интерфейса.

Сообщение отредактировано: Qraizer - 17.02.14, 12:37

Тебе просто нужно избавиться от наследования головного мозга. Все же очевидно: раздели сущность, мухи отдельно, котлеты отдельно.

Что, наследование - это плохо, да?

Цитата D_KEY @ 17.02.14, 15:57

Что, наследование - это плохо, да?

Местами да, плохо.