Почему нельзя было реализовать множественное наследование?

[ZackMercury]

Логичней всего сделать слайдер, унаследованный от Sprite и EventDispatcher, и отправляющий свои события CHANGE, чем создавать внутри себя экземпляр EventDispatcher'a, и пользователей класса подписывать на него.

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

[СлаваRa]

Sprite и так наследуется от EventDispatcher в чем проблема?

[ZackMercury]

Сообщение от СлаваRa

Sprite и так наследуется от EventDispatcher в чем проблема?

О, а я и не знал...

[Akopalipsis]

Вы никогда не подписывали спрайт на событие?)

[ZackMercury]

Сообщение от Akopalipsis

Вы никогда не подписывали спрайт на событие?)

Я подписывал на событие ADDED_TO_STAGE, и прочие, но не задумывался насчёт этого)
И скорее всего Sprite унаследован в первую очередь от DisplayObject, а тот неким образом уже связан с EventDispatcher'ом. Доки лень гуглить.
Чёто-помнится мне из книги Мука про интерфейс IBitmapDrawable, который реализуется всем, что должно по идее рисоваться на сцене.

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

[caseyryan]

Доки лень гуглить.

А кто-то еще говорит, что живет программированием.. ) Да да, охотно верится

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

И скорее всего Sprite унаследован в первую очередь от DisplayObject, а тот неким образом уже связан с EventDispatcher'ом. Доки лень гуглить.

Sprite - DisplayObjectContainer -InteractiveObject - DisplayObject - EventDispatcher - Object

Это заняло секунд 5 - 7. На написание поста на форуме ты, очевидно, потратил намного больше времени

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

[expl]

Если нет, то почему Adobe отказалась от множественного наследования?

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

Основная - проблемы с реализацией сборки мусора в языке с множественным наследованием
Побочная - разрешение всяких конфликтов наследования неминуемо усложнит компилятор и язык

Adobe - не специализируется на компиляторах и языках программирования, как бы они смогли сделать _жизнеспособный_ язык с множественным наследованием, когда мейнстрим "языкостроения" (C#,D,Java) от него отказался? Овчинка выделки не стоит, угробили бы кучу денег на исследования и всё.

[caseyryan]

Овчинка выделки не стоит, угробили бы кучу денег на исследования и всё.

Вот именно. Я лично вообще не вижу плюсов множественного наследования

[Rzer]

http://help.adobe.com/en_US/FlashPla...s.html#include - пиши куски кода и вставляй их куда душе угодно!

[СлаваRa]

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