2 Zeroglif >
А как там ( self ) решена проблема неоднозначности, когда несколько предков имеют метод с одинаковой сигнатурой и экземпляру потомка нужно вызвать метод с такой сигнатурой ?
2 Dmitry A. Soshnikov>
аналогичный вопрос с проблемой неоднозначности в мозилле как можно решить ?
Кстати, а цепь прототипов какого предка просматривать первой, какого второй и т.д. ?

kefi,

тынц

2 Zeroglif > Ну насколько я смог оттуда понять, SELF используют симбиоз упорядоченного и неупорядоченного множественого наследования, разбивая предков на группы по приоритетам, внутри группы разрешение имен - неупорядоченное, между группами - предпочтение отдается имени предка из более приоритетного уровня .
Причем, не знаю , верно ли я понял , неупорядоченное (это то ,что в C++) приводит к run-time ошибке при обращении к двусмысленным именам слотов ( т.е. именам имеющимся у нескольких родителей), т.е. получается проблема эта в C++ не решается, точнее компилятор заставляет програмиста обходить ее.

А какая неоднозначность, если множественного наследования нет? С Мозиллой лишь приводил одну из имитаций.

У объекта одна цепь прототипов. А в __noSuchMethod__ Вы уже сами определяете к каким объектам делегировать за нужным (не найденным в цепи) методом.

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

по поводу статика vs динамика, думаю статика лучше для статичного кода (который не будет сильно изменяться, например, библиотеки), а динамика для динамичного (например, пользовательский интерейс). Т.е. динамика облегчает изменение кода
по поводу множественного наследования (как в C++): первый вопрос, который стоит задать - зачем оно нужно? По-моему в основном для каких-то хаков библиотек, что можно обычно сделать за счет динамики языка (мне кто-то вроде приводил пример)
кроме того, вспомнилась фраза про множественное наследование в Perl, но решил также оставить описание проблем:

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

Но тем не менее она решается так или иначе. У природы тоже не всегда получается межвидовое(или, как там правильно,- межсемействами) скрещивание, какие-то получившиеся виды (Лошадь+Осел -> Мул ) дают вполне рабочий вариант , который правда далее не скрещивается ни с кем , Но в одном-то поколении его можно использовать.
И проблемы действительно можно доверять программисту

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

как и C++.

а можно реальный пример множественного наследования, когда оно нужно?

Из PrototypeJs:

Не множественное, но думаю продолжить не проблема:
Enumerable > Hash
Enumerable > ObjectRange

А вот здесь множественное:
Ajax.Base > Ajax.Request > Ajax.Updater
PeriodicalExecuter > Abstract.TimedObserver > Form.Element.Observer
PeriodicalExecuter > Abstract.TimedObserver > Form.Observer

Riim,
а множественное наследование где?

К тому же все (ну или почти) наследует от Object, так что цепочки Enumerable > Hash и Enumerable > ObjectRange можно переписать как:
Object > Enumerable > Hash
Object > Enumerable > ObjectRange