Разница между willTrigger и hasEventListener

[Psycho Tiger]

Разница между методами hasEventListener() и willTrigger() заключается в том, что hasEventListener() просматривает только тот объект, которому принадлежит, а willTrigger() просматривает весь поток событий для события, указанного в параметре type.

Делаю тест - willTrigger ловит события родителя и своё в иерархии дисплай листа, hasEventListener ловит только своё.
Вопроса бы не возникло, если бы willTrigger объявлялось в DisplayObject. Вне DisplayObject`ов я не могу найти разницы. Это идиотизм или я недостаточно хорошо ищу?

[switcher!]

судя по всему адобовцы исходили из принципа тематического единства, а не видимой необходимости того или иного свойств в классе. На эту мысль наводят некоторы факты:

- наиболее очевидный - это то, что в некоторые классы заложена функциональность, которой там по идее не должно быть. Например, TextField и SimpleButton контейнерами не являются, однако, могут иметь детей, и даже диспатчаться события их добавления. Т.е. внутренние механизмы деторождения заложены в вышестоящем классе и, скорей всего - это DisplayObject.
- далее, метод dispatchEvent оверрайден минимум один раз в пути до Sprite. Это доказывают нехитрые тесты. Это значит, что проблем с вызовом super методов нет ни разу. И можно было спокойно определить willTrigger в DisplayObject, а внутри пробегаться по парентам с super.hasEventListener

[Psycho Tiger]

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

Нет, просто в хелпе в цепочке наследования пропущен DisplayObjectContainer.

- далее, метод dispatchEvent оверрайден минимум один раз в пути до Sprite. Это доказывают нехитрые тесты.

Что то в голову не приходят идеи как это можно проверить. Поделитесь идеей, пожалуйста.

И можно было спокойно определить willTrigger в DisplayObject, а внутри пробегаться по парентам с super.hasEventListener

Так то понятно, но зачем переопределять то, что раньше по идее не должно было быть предопределенно? Похоже, это действительно идиотизм.

[wvxvw]

Вне дисплей обжектов нет разницы.

[Psycho Tiger]

Понятно, идиотизм. Спасибо.

[Котяра]

просто подразумевается что вне дисплэйобжектов бабблинга не существует ( по сути так и есть)
если хочешь реализлвать свою систему всплытия, например, для Model`ей переопредели willTrigger под себя.

[Psycho Tiger]

Не не, про бабблинг у Event`ов понятно - в конструкторе объявить дополнительный аргумент это вполне удобно.
Меня интересовал момент, почему эта вещь по идее должна быть объявлена в DisplayObject`е, но почему то объявлена в EventDispatcher - значит вполне возможно я не понимаю чего то в механике, ради чего и была поднята эта тема.

[wvxvw]

Я думаю, что реализация такая, какая она есть потому, что ее не придумывали специально для флеша, а скопировали DOM3 события не особенно задумываясь о логике.

[switcher!]

Сообщение от Psycho Tiger

Нет, просто в хелпе в цепочке наследования пропущен DisplayObjectContainer.

наследование в AS3 предполагает получение наследником ВСЕХ свойств. Это значит, что будь SimpleButton наследником DisplayObjectContainer, то как минимум можно было бы вызвать addChild, пусть даже он был переопределен на выброс ошибки. Однако, этого сделать нельзя.

Хорошо, допустим в плеере нативные классы сделаны на си с возможностью наследования реализации (я в си не знаток, но допустим). И копируются только внутренние механизмы DisplayObjectContainer. Тогда на кой черт в свободном доступе (хоть и переопределенными) у Stage оставили весь этот балласт из неиспользуемых свойств? Исключительно потому что "официально" Stage наследуется от DisplayObjectContainer? Типа "спалились"? Это глупо.

И потом, подобные финты с сокрытием реальных родителей (в цепочке наследования) чреваты костылями. Например, в describeType писать:

if (value is SimpleButton || value is TextField) /*скрываем DisplayObjectContainer*/;

или заводить отдельное свойство/объект, которые содержит то, что нужно показать программеру, в противовес реальному.
Так что ли ?

Сообщение от Psycho Tiger

Что то в голову не приходят идеи как это можно проверить. Поделитесь идеей, пожалуйста.

потести скорость диспатча без баблинга: EventDispatcher, Sprite и наследника EventDispatcher с переопределенным dispatchEvent. Например так:

override public function dispatchEvent(event:Event):Boolean {
	var b:Boolean = true;
	if (b) return super.dispatchEvent(event);
 
	return false;
}

[incvizitor]

var tf:TextField=new TextField();
trace(tf is DisplayObjectContainer);
 
var btn:SimpleButton=new SimpleButton();
trace(btn is DisplayObjectContainer);

Вывод:

false
false