Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)
-   -   Почему нельзя было реализовать множественное наследование? (http://www.flasher.ru/forum/showthread.php?t=207556)

ZackMercury 23.04.2014 01:01

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

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

СлаваRa 23.04.2014 01:05

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

ZackMercury 23.04.2014 01:11

Цитата:

Сообщение от СлаваRa (Сообщение 1164304)
Sprite и так наследуется от EventDispatcher в чем проблема?

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

Akopalipsis 23.04.2014 01:30

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

ZackMercury 23.04.2014 01:42

Цитата:

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

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

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

caseyryan 23.04.2014 07:54

Цитата:

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

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

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

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

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

expl 23.04.2014 18:32

Цитата:

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

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

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

caseyryan 23.04.2014 19:44

Цитата:

Овчинка выделки не стоит, угробили бы кучу денег на исследования и всё.
Вот именно. Я лично вообще не вижу плюсов множественного наследования

Rzer 23.04.2014 20:29

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

СлаваRa 24.04.2014 00:20

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


Часовой пояс GMT +4, время: 22:02.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.