addEventListener. Зачем в параметрах функции писать event:MouseEvent?

[caseyryan]

Часто? Совсем нет. Это редкий случай. В большинстве случаев это не оправдано.

[expl]

MouseEvent - расширяет Event, следовательно MouseEvent не обязателен, т.е. место него можно поставить Event параметр - вот он точно обязателен

Тут спорный момент.
Если вам не нужен объект события, можно вообще написать

private function onClick(...args:Array):void

И тогда кто бы её не вызвал - ничего не упадет.
Но и когда параметр потребуется - придётся вспоминать, можно ли здесь заменять на event:MouseEvent/event:Event и править код.

Что касается MouseEvent или Event тут палка о двух концах:

- Если написать Event:
Плюсы: если Вы нечаянно(можно на автомате написать MouseEvent вместо Event) или специально повесите этот обработчик на источник _не_ MouseEvent - то ничего не упадёт, часто хватает и методов Event (остановить распространение событий, например),
а mouseX и mouseY обычно надёжнее взять у объекта напрямую, а не у event.
Минусы: если потребуется использовать именно MouseEvent в обработчике, то придётся вспоминать, а что сюда на самом деле передаётся и можно ли переправлять на MouseEvent

- Если написать MouseEvent:
Плюсы: видно, что можно использовать поля MouseEvent в обработчике.
Самый очевидный плюс: Можно меньше думать!

    addEventListener(MouseEvent.CLICK, onClick) - значит пишем onClick(event:MouseEvent)
    addEventListener(Event.ADDED_TO_STAGE, onAddedToStage) - значит пишем onAddedToStage(event:Event)

Что в подписке - то и в слушателе!
Плюсы/Минусы: при рефакторинге огребал с падением, когда нечаянно перевешивал листенер не туда
но и узнавал зато, что не туда перевесил, но иногда без разницы на что вешать, но и падает не сразу, при определённых действиях. А если в релизе так упадёт? Короче спорный момент.

Вобщем, компилятор здесь параметры слушателя не проверит - нет средств таких в API флешплеера и в языке.
Плюсы/минусы не очевидны.
Я и так и так поступаю - под настроение.
А Вы делайте как нравится

[СлаваRa]

Зачем изобретать костыли, почти все редакторы генерят хендлеры самы.

зы
видел я такой код onClick(...args), готов был прострелить коленки автору.

[expl]

видел я такой код onClick(...args), готов был прострелить коленки автору.

Просто не надо так писать, если это фрустрирует коллег.
Ну и ...args подразумевает, что параметров может быть и 0 и 1 и 2, тоже с толку сбивает.

[СлаваRa]

Человек, который писал, работал один.. Кто-то его научил такому "трюку", и он стал писать так везде, прошло несколько лет и людям с других команд пришлось работать с его кодом. И тут началось много интересного...
Когда я вижу такие советы, мне всегда хочется, увидеть описание зачем так делать и что в этом хорошего.

[caseyryan]

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

Тут спорный момент.
Если вам не нужен объект события, можно вообще написать

private function onClick(...args:Array):void

И тогда кто бы её не вызвал - ничего не упадет.

Варарги не типизируются Это в любом случае массив.
так что:

rivate function onClick(...args):void

Я знаю, что ты это знал Но не мог пройти мимо )

[expl]

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

Я подумал и действительно не могу придумать случай, когда ...args будет чем-то лучше event:Event = null в обработчике.
Хотя чтобы из-за ...args можно было бы огрести тоже не скажешь - нечасто кто-то будет пытаться вызвать этот обработчик с аргументами (1, 2) вместо () или (null) или (new Event(..)), а потом думать почему аргументы 1 и 2 не учитываются при работе функции.
(имеется в виду по багам, а злобу коллег можно и от переноса строк в непривычном месте заиметь).

Я знаю, что ты это знал Но не мог пройти мимо )

Хорошо, давайте скажем прямо:
Новички! Не надо писать так:

private function onClick(...args:Array):void

Не надо!

[Psycho Tiger]

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

И только это?