зачем нужны примеси, если есть множественное наследование?

Пары полиморфизмов хватит всем.

Каких? Статического и динамического?

По сути дела так оно и вышло, примеси в Scala – это множественное наследование с определёнными ограничениями.

Думается, что пойдя по другому пути, через непосредственное наследование классов, получили бы проблемы с совместимостью с Java.

скалавские traits очень напоминают множественное наследование в common lisp. Та же линеризация при наследовании, только порядок по-моему обратный. Так же нет явного конструктора. Как будто создатели common lisp предвидели, что лучше инициализировать объект через метод. Только распиарены, конечно, эти traits по самые гланды, хотя основная идея была реализована в common lisp еще лет 35 назад

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

Нашёл про линеаризацию, теперь надо разбираться.

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

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

Не знаю ни одного человека, который произошёл только лишь от одного родителя.

Это потому что их всех убивают на этапе эмбрионов, как того требует законодательство.

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

Жабер поди? Обычно они компенсируют убогость своего языка такими заявлениями.

Жабер поди?

Жабер умер, как и ICQ.

интерфейсы, сээр

class Child implements Mother, Father {}

или

abstract class Parents implements Mother, Father {}

class Child extends Parents {}

Это убогость плюсов пытаются выдать за свободу в дизайне. Только вот дизайн получается тоже убогий.

в этом коде не хватает толерастии.

То ли тонко, то ли с инглишем совсем плохо.

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

#!/usr/local/bin/io


Foo := Object clone do(a := 1)
Bar := Object clone do(b := 2)

Moo := Object clone do(c := 3; appendProto(Foo); appendProto(Bar))
Noo := Object clone do(c := 4; appendProto(Foo); appendProto(Bar))

test := method(writeln(a + b + c))

Moo test // 6
Noo test // 7

Foo a = 10
Bar b = 20

Moo test // 33
Noo test // 34

тонкости нет, написал что просили, инглиш не причем, а вот с пониманием русского у кого-то проблемы, это да

Анонiмус снова с нами!

Это убогость плюсов пытаются выдать за свободу в дизайне. Только вот дизайн получается тоже убогий.

Т.е. насчет Java угадал, окей, а убогость Java наглядно показывают твои потуги и костыли. Которые кстати споткнуться сразу же, как ты поймешь, что Father и Mother это Human и имеют общую часть реализации.

Это убогость плюсов пытаются выдать за свободу в дизайне.

Причём тут убогость плюсов? :-) Причём тут свобода в дизайне? :-) Это классический приём в технологии объектно-ориентированном проектировании :-) Проект должен максимально отражать реальность :-) А в реальности, потомок имеет двух родителей :-)

То, через сколько указателей в vtbl это реализовано в цепепе или ещё где-то - вопрос отдельный, не имеющий отношения к проектированию вообще :-)

Это классический приём в технологии объектно-ориентированном проектировании :-) Проект должен максимально отражать реальность :-)

Этот бред давно уже считается бредом.

А в реальности, потомок имеет двух родителей :-)

Биологическое отношение «родитель-ребенок» не моделируется ООП-отношением «is-a». Внезапно, да.

Этот бред давно уже считается бредом.

Разве что на твоём локалхосте :-)

Биологическое отношение «родитель-ребенок» не моделируется ООП-отношением «is-a». Внезапно, да.

А что если это некая Барбара со своими подстановками бредит, а? :-)

но примеси сами по себе могут образовывать ромб

Не могут

Более того, отсутствие множественного наследования с концептуальной точки зрения попахивает тухлячком. Например, если Вася рдновременно футболист и повар, то от кого его наследовать, от футболиста или повара?

А в реальности, потомок имеет двух родителей :-)

Биологическое отношение «родитель-ребенок» не моделируется ООП-отношением «is-a». Внезапно, да.

А что если это некая Барбара со своими подстановками бредит, а? :-)

Барбара не говорила о реальности и родителях. Ты ее неправильно понял. Что, впрочем, неудивительно.

что примесь не существует сама по себе, потому её и нельзя создать.

Отчего же? В нормальных языках это просто объект

O := Object clone addTrait(Object clone do(a := 1; b := 2))

Барбара не говорила о реальности и родителях. Ты ее неправильно понял. Что, впрочем, неудивительно.

Интересно, как же, если не через Барбару, ты собрался доказывать вот этот свой комментарий:

Биологическое отношение «родитель-ребенок» не моделируется ООП-отношением «is-a».

А? :-)

А что если это некая Барбара со своими подстановками бредит, а?

Дык, бабам вообще не место в инженерных дисциплинах:)

«Вася» это класс?!

Более того, отсутствие множественного наследования с концептуальной точки зрения попахивает тухлячком. Например, если Вася рдновременно футболист и повар, то от кого его наследовать, от футболиста или повара?

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

скорей объект, экземпляр классов повар и футболист, в данном случае. Но это не столь важно, класс или не класс

Ещё немного, и ты дойдёшь до идеи type classes.

Вася может потерять ноги и перестать быть футболистом.

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

Вася может потерять ноги и перестать быть футболистом.

Ага, а если с автомобиля снять колёса, то он перестанет быть автомобилем :-) И станет Васей, да? :-)

Что за Барбара, это, что ли?

Пусть q(x) является свойством верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.

Ну пожалуйста:

как же ... доказывать «Биологическое отношение «родитель-ребенок» не моделируется ООП-отношением «is-a».»

А очень просто: в реальности дети за родителей не отвечают.

Барбара не говорила о реальности и родителях. Ты ее неправильно понял. Что, впрочем, неудивительно.

Интересно, как же, если не через Барбару, ты собрался доказывать вот этот свой комментарий:

Барбару попытался притянуть ты. Я ничего не собираюсь доказывать через нее.

Биологическое отношение «родитель-ребенок» не моделируется ООП-отношением «is-a».

А? :-)

Ребенок не является своим родителем. Ты не понимаешь таких простых вещей?

Барбару попытался притянуть ты. Я ничего не собираюсь доказывать через нее.

Зря :-)

Ребенок не является своим родителем. Ты не понимаешь таких простых вещей?

Потому что ребёнок и родитель - суть разные объекты :-) А то, что ребёнок носит гены обоих родителей, ты не понимаешь таких простых вещей? :-) А то, что в некоторых случаях только ближайший родственник, т.е. может быть донором, например? :-) Ты про «общность» слышал что-нибудь? :-) Или про «узкий» интерфейс (так к народу ближе) :-)

Потому что ребёнок и родитель - суть разные объекты

Это суть разные состояния во времени одного объекта.

А очень просто: в реальности дети за родителей не отвечают.

Это кто как воспитан :-)

Это суть разные состояния во времени одного объекта.

Это всё домыслы :-)

Причём, неисключающие друг друга, гы-гы-гы-гы.

Причём, неисключающие друг друга, гы-гы-гы-гы.

Ага, и существующие параллельно и всегда :-)

Предлагаешь сделать Повара и Футболиста тайпклассами?!

Я бы сказал перпендикулярно и никогда.

Ребенок не является своим родителем. Ты не понимаешь таких простых вещей?

Потому что ребёнок и родитель - суть разные объекты :-)

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

А то, что ребёнок носит гены обоих родителей, ты не понимаешь таких простых вещей? :-) А то, что в некоторых случаях только ближайший родственник, т.е. может быть донором, например? :-)

Началось натягивание совы^Wбиологии на глобус^WООП.

А тайпклассы — это разве не те же трейты? К чему там доходить то?

Притянутый за уши пример.

А Вася - перманентый фуболист и повар, нет?

Если Вася наследует только от футболиста, и теряет ноги, значит и одиночное наследование неправильно по этой логике?

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

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

Это было бы так, если бы оба родителя были бы абстрактными сущностями, которые не могут существовать сами по себе в принципе :-) Но они являются сущностями конкретными и, как и их потомки, могут существовать отдельно, прямо как в реальности :-) Изъясняясь в терминах цепепе, классы Father, Mother и Child - конкретные классы с конструкторами :-) Кстати, это ещё один пример того, что полноценное множественное наследование - вполне оправданная концепция, в отличии от т.н. «интерфейсов» :-)

А Вася - перманентый фуболист и повар, нет?

Предполагается что да, в данном случае.

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

В чем проблема изменяемости(для нормальных ООП языков)? В чем конкретно проблема? Приведи пример, пожалуйста

Началось натягивание совы^Wбиологии на глобус^WООП.

Нет, начался активный поиск общности, как то велел делать тот же Страуструп :-)