Организация работы событий

[Psycho Tiger]

Да, etc прав. Вся инкапсуляция и тому подобное было сделано ради защиты от дураков. Защиты от идиотов же не существует. Я найду способ сломать событие и с геттерами. Например, остановлю его.

[mikhailk]

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

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

Но, это лично мне так нравится.
Совсем не обязательно, что так правильно.

[Psycho Tiger]

mikhailk, у нас речь не о обмене сервер-клиент, а о событиях в самой флешке. Наследники flash.events.Event так сказать)

[Mur4ik]

Если все события генерирует один объект, то можно предположить, что все параметры передаваемые через события как то связаны или имеют принадлежность к какой то сущности. Можно сделать и один класс события в котором будет один параметр представляющий собой класс, который содержит в себе нужные строго типизированные свойства (т.н. value object). Т.е решение подобное ому как делает Psycho Tiger, только не в ущерб типизации, автокомплита и т.д.

[koIIImarik]

2 Mur4ik:
Как мне кажется, ваш вариант подходит в том случае, если этот объект с типизированными переменными будет использоваться ещё где-нибудь (допустим его будут передавать в качестве параметра для создания объектов на основе этого объекта), иначе, как мне кажется, нет смысла переносить список переменных из Event объекта в какой-то другой объект, потому что по сути добавляется только 1 промежуточный этап на пути доступа к переменным.

[Mur4ik]

Не спорю.
Просто если параметры передаваемые событием связаны, то мне удобнее видеть их в одном объекте, который их характеризует, вместо того чтоб в классе события создавать 5-10 параметров, с которыми работа только усложняется, особенно в случае когда нужно передать большую часть из этих параметров (имеется ввиду инициализация события). А вот имея один-два типизированных объекта все становится прозрачнее и удобнее, ИМХО.

[Psycho Tiger]

Попробуйте сделать

super.addEventListener(YourEvent.EVENT, super.dispatchEvent);

[switcher!]

да, при редиспатче поюзанного эвента - он клонируется. Видимо, идет проверка а-ля:

if (event.$target) //внутренний internal таргет
{
	event = event.clone();
}

Благо EventDispatcher и Event лежат в одном пакете. Однако, это домыслы, ибо неизвестно, что в тамошних сях записано.

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

[fljot]

Хм да, я тоже несколько удивлён=) etc, не разъяснишь?

[Psycho Tiger]

Событие клонируется при нативном EventDispatcher::dispatchEvent`е.