О, у вас отношения уже?

:D :no:
Это он про это:

я, конечно, поздновато присоединяюсь, но... Kolyaj, а когда нужно?

не понятно зачем туда входить... да и способ сам сомнительный больно

У всех свои цели в жизни:)
Я нехочу, но может кто другой...
Да, есть такое...

Класс Observer, например. Есть у тебя класс A, ты хочешь отнаследовать от него класс B и добавить туда возможность генерации событий. В том же Python'е, ты бы просто отнаследовался также и от Observer, тут же тебе придется или ставить Observer в корень наследования, или реализовывать в классе B нужную функциональность, или реализовывать Observer так, чтобы он мог приклеиваться к любому объекту.

Kolyaj а у тебя какой стаж JS
Оо я уже профессор

JSprog,
а ты с какой целью интересуешься? :)

С целью узнать за скоко времени ты достиг такого професионализма

Об этом, по-подробнее можно написать тут, если не против, конечно:)

Рано мне еще автобиографию писать. )))

JSprog,
если интересно, то начал в начале 2006 года, но многое узнал за последний год, когда начал заниматься только JS.

Какие все стеснитильные:)

Есть идея про мн наследование просто использовать расширение функций вообще без наследование а фабрикой объектов

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

Да и вообще я схему себе не очень представляю, если например (не касаясь JavaScript) один класс наследует два других класса, которые имеют одинаковые имена методов, то что происходит? Простое перекрытие, или образуются "суб-пространства" имен?

множественное наследование, как я понимаю, имеет смысл для наследования реализации и немного проще других вариантов

это, имхо, скорее либо из области теории (если разумно его применять проблем не будет), либо из больших древних или запущенных проектов

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

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

Думаю на этом можно закончить:)

Множественное наследование - это шаг к усилению абстракции и упрощению реюза кода (действительно, раз научились наследовать код от одного блока, давайте научимся сразу от десяти - удобный способ повторно использовать этот код). Однако, имеет свои недостатки (поэтому, и не прижился во многих языках), одна из которых (и, возможно, основная) - Diamond problem (то, о чём спрашивал Андрей Параничев): решение зависит от реализаций, но в целом, в теории, этот алгоритм называется Method resolution order (порядок разрешения имён методов), или линеаризацией - C3 linearization - суть: выстроить (линеаризовать) дерево методов так, чтобы не возникло конфликтов имён (т.е превратить в цепь).

Альтернативой множественному наследованию являются интерфейсы и примеси (ну это и так все знают ;)).

а где тут усиление абстракции?

т.е. это фактически как составляющие наследования: наследование интерфейса и наследование реализации

p.s. еще можно почитать
http://phpclub.ru/talk/showthread.ph...E2%E0%ED%E8%E5
http://phpclub.ru/talk/showthread.ph...E2%E0%ED%E8%E5

Можно сказать, что объект D включает в себя сразу 3 объектов (A, B,C); при этом реализация объектов А, B, C может быть не столь важна при абстрактном описании объекта D.

во-первых это слишком абстрактное (:)) объяснение, во-вторых я его не понял, а в-третьих, объекты становятся более абстрактными по мере продвижения к корню иерархии и множественное наследование класса никак не влияет на абстрактность своих родителей
UPD: или речь о том, что множественное наследование - более абстрактное по сравнению с обычным?

Ага. С этой точки зрения, да. Более "безликими", "неконкретными". Я имел в виду больше повторное использование кода, когда объект будет иметь нужные свойства/методы, но говорить о них можно полностью абстрактно (т.е. объект умеет "печатать" - унаследовал от одного объекта, "прыгать" - от другого), не касаясь реализации (которая находится ниже), но, возможно, в данном случае, несколько путано донёс смысл.

Основная речь была о code reuse.

Я имею ввиду проссто копировать свойства из одной функции в другую. И поставить более приоритетный класс.ариме если есть два метода с одинаков названием в родителях то копируетса метод из приоритетного класса второй также копируетса но с изменёным названием на 1 заданный символ

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

При втором уровне наследования еще символ добавлять? А если там уже есть метод с таким символом, третий добавлять? И как теперь понять с какого уровня наследования этот метод?

Ну тогда через ссылки parent1.method, parent2.method, parent1.parent2.method

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

А так не пойдет?

function Constructor () {}
Constructor.prototype = new Array();
Constructor.prototype.method = function (){};

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

простое перекрытие тот что позже наследовался те и методы