Понимание ООП в JavaScript

[kefi]

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

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

а цепь прототипов какого предка просматривать первой, какого второй и т.д. ?

[Zeroglif]

kefi,

тынц

[kefi]

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

[Dmitry A. Soshnikov]

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

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

а цепь прототипов какого предка просматривать первой, какого второй и т.д. ?

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

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

[x-yuri]

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

Хотя в большинстве ОО-языков разрешено наследование более чем от одного класса, такая возможность порождает больше проблем, чем преимуществ. Например, с точки зрения разработчика компилятора совместить множественное наследование и эффективное использование ресурсов компьютера (память и скорость работы) - нетривиальная задача...
Однако проблемы имеются и с точки зрения пользователя. Они возникают в случае, когда "по наследству" передаются одноименные поля данных и методы. Возникает ряд вопросов. Какой именно метод и какое именно поле данных (и в какой форме) должны остаться в результирующем объекте? Как в случае существования перекрывающихся полей и методов должны функционировать методы, заимствованные из разных классов? Например, что делать, если поле DATA, в котором наследуемый из класса ClassA методожидает найти целое число, совместилось с полем DATA из класса ClassB, который использует его как текстовую строку? Обратная ситуация - что делать, когда и в классе ClassA, и в классе ClassB есть методы getdata, но они выполняют принципиально различные операции? Особым случаем совпадающих имен является вариант, когда оба класса, ClassA и ClassB, наследуют от общего класса Class0, - должны ли мы сохранить 2 копии полей данных или достаточно одной? В каком порядке и как следует вызывать конструкторы, чтобы правильно инициализировать поля данных? В каком порядке будут вызываться деструкторы и как они будут взаимодействовать друг с другом? И подобным проблемам несть числа, стоит только начать разбираться
В отличие от большинства других ОО-языков программирования, где бесконфлитное разрешение подобных ситуаций представляет серьезную проблему для автора языка или разработчика компилятора, Perl справляется с трудностями просто - он передоверяет их пользователю

[kefi]

зачем оно нужно? По-моему в основном для каких-то хаков библиотек,

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

нетривиальная задача...

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

методожидает найти целое число, совместилось с полем DATA из класса ClassB, который использует его как текстовую строку

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

Perl справляется с трудностями просто - он передоверяет их пользователю

как и C++.

[x-yuri]

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

[Riim]

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

Из PrototypeJs:

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

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

[Kolyaj]

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

[Riim]

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