Суть та же, все уже сделано, велосипеды от лукавого.
Сам спросил — сам ответил.

Ну вместо "передачи функции куда-либо по ссылке" напишите "подписка обработчика". Плюс т.к. как минимум обработчик может быть не один и просмотреть все обработчики нет возможности, то отследить. что происходит может быть сложнее.

Это написано после моего сообщения, и видимо относится ко мне? Не надо искать новых оппонентов, у Вас их достаточно. Я всего лишь пытаюсь развеять некоторые заблуждения, поделившись опытом. Вы конечно вправе цепляться за них, искать цитаты в мировой литературе, громыхать именами – я и сам так делаю, когда нужно. Вы для себя решите, что для Вас лучше: отстоять свою "правоту" или разобраться в вопросе и повысить скиллы? Потому что я как модератор не вижу диалога, вижу Вас в боевой стойке с выдранной из Мука страницей. Из Мука, которого большинство Ваших оппонентов прочитали и изучили не по одному разу, и не по десятку раз использовали на практике. Я советую Вам перестать огрызаться и начать разговаривать. Польза от этого будет Вам в первую очередь. А заодно и нам, когда мы услышим Ваши доводы и мысли.
Пока что было приведено три довода.
1) Удобство отключения слушателя для множества объектов.
Ну я показал, как это делается без костылей, стандартными методами ActionScript, созданными как раз для этого.
2) "то как реализовано у меня больше похоже на полиморфизм".
Полиморфизм имеет очень четкое определение, на него не может быть "похоже". Полиморфизм это когда объект одного типа может быть безопасно заменен объектом другого типа. Например в addChild() вы можете передать как Sprite, так и TextField. То, что Вы одну Function заменяете на другую Function, к полиморфизму никакого отношения не имеет. Поскольку в ActionScript отсутствуют шаблоны типов, функции не могут быть "типизированы", то есть их сигнатура не может быть гарантирована непосредственно, а только через интерфейс объекта-хозяина. Если в вашу кнопку передать метод, требующий параметры, произойдет исключение. И механизма контроля нет. Именно поэтому в ActionScript коллбэки нарушают ООП. В языках с шаблонами типов этой проблемы нет, и там использование коллбэков никого не напрягает.
Если хотите поддержку из мира ООП, ссылайтесь не на полиморфизм, а на паттерн Command (Action). Вот от него тут есть что-то))
3) Страничка из Мука.
Централизация не значит "коллбэки". Более того, централизация не значит "централизация всего и вся".
Есть (должна быть) иерархия, в этом суть ООП, в разделении на объекты с ответственностью. Вы пытаетесь всю ответственность отдать одному классу. Это сломает иерархию и все ее плюсы. В приложении должны быть выделены несколько модулей. Каждый отвечает за какой-то функционал. Допустим есть Меню, есть Статья, есть Галерея фоток. Каждый из этих модулей должен иметь свою специфическую логику, работая со своими частями. Главный класс вовсе не обязан знать все о картинках галереи и разбираться с их поведением. Он "общается" с Галереей, а Галерея управляет картинками. Вот в отношениях Галерея > картинки безусловно хороша централизация. Нет смысла вешать слушатели на каждую картинку, потому что действия идентичны. А если действия разные, централизация превращается в батарею свитчей и такие прелести ООП как повторное использование, расширяемость, абстрактность и полиморфизм исчезают навсегда. Пока у вас только кнопки, то есть все фигуранты одного типа, все нормально выглядит. Когда Мейн будет ловить и обрабатывать клики и от кнопочек Меню, и от картинок Галереи, вам никакая страница Мука не поможет, ибо это по ту сторону логики, и Мук туда не хаживал. Не цепляйтесь за буквы, выдранные из контекста.

Добавлено через 2 минуты
Пока писал, целую страницу накатали))
Рад что стало походить на диалог.

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

И это хорошо.
Сигналы - это тоже альтернативный велосипед. Правда списанный с сишарп и QT.
Но ведь хороший велосипед.

Странные люди ищут более простые решения для конкретных задач, только и всего. ООП хороша для сложных систем, но как все универсальное и при этом безотказное – слишком сложна и избыточна. Событийная модель в том числе: гибкая, но оттого же и тяжелая. Чаще всего мы не используем и десятой доли заложенного в ней функционала (как и во многом другом). Люди ищут варианты без лишних фич, это нормально. Кто-то использует мегабайтные сторонние библиотеки чтобы загрузить и вывести картинку на экран, и это тоже нормально)) Главное понимать, что и зачем, а не упираться рогами в концепции.

Но дело в том, что события зашиты в плеер и если мы будем использовать кастомные решения мы никак не выиграем ни в весе ни в скорости (хотя в скорости иногда можно выиграть всё-же: в блоге wvxwv есть его велосипедные сигналы, и они, вроде как, быстрее даже)

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

у меня кнопки нажимаются мышкой, одновременно можно мышкой нажать только 1 кнопку (потому что только один курсор). Различия скорости выполнения в наносекундах в данном случае не критичны

Мне вот больше интересно другое.
Мы в кнопке подписываемся на клик, чтобы вызвать метод, который передали в кнопку по ссылке.
А почему нельзя сразу подписаться на клик с нужным методом?

Кто "мы"? Ты про что? Речь как раз о централизации, то есть никакая кнопка никаких отношений с кликами не имеет. Подписывается контейнер (в случае автора - стейдж).

Добавлено через 9 минут
Кнопка хранит примитивную Command/Action. Это то же самое (типа), что хранить id, и потом в Большом Центральном Кликоразделителе выуживать этот id у таргета и по нему определять метод, который запускать (что конечно было бы приятней, так как дает больше свободы с параметрами).
Если сделать подписку и execute() внутри кнопки, то есть она сама ловит клик по себе и запускает акцию, то это потребует еще кучу наворотов для контроля состояний кнопки в зависимости от ситуации с приложением. Это такая децентрализация, которая хуже мегацентрализации, имхо, так как будет рождать баг на баге и потребует кучи каких-то сомнительных условий и угловатых стежков. Впрочем, как и обычное решение на событийной модели ;)

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

Не правильно. Конструктор есть всегда, даже если не указан явно. Правило хорошего тона - всегда писать конструктор.

а он не унаследуется от супер-класса? я с этим классом нигде new использовать не буду, в нём кроме статики ничего не будет

Добавлено через 32 секунды
а туплю.. супер класса нету =)

Правила хорошего тона все равно остаются ;)

кароче у меня теперь срабатывают обработчики событий и кнопки в которую тыкнул и спрайта в котором эта кнопка лежит одновременно... как лечить?

Добавлено через 5 минут
третий аргумент сделать тру?

Добавлено через 7 минут
не....

надо прототипу спарйта тоже свой action назначить, не? будьте последовательны.

я экшины убрал уже

Смотрите кто у события target и принимайте решение что нужно сделать

т.е. когда у меня был один хендлер, смотреть в таргет было плохо, а когда я сделал 2 хендлера, проверять таргет 2 раза стало хорошо?

Различие знаете target и currentTarget?

Тоже не понял... У Вас теперь подписка И на контейнер, И на каждую кнопку?

да...

Так если каждая кнопка вызывает свой конкретный хендлер, то зачем общий на контейнере?
Либо, если есть Большой Центральный Кликоразделитель, то зачем каждой кнопке свой конкретный слушатель?
Вы уж выберите одно из двух.
У меня в том примере слушатель на контейнер повешен с одной целью - отловить событие клика в фазе захвата и остановить его, пока событие не дошло до кнопок в контейнере.
А если Вы ловите все события контейнера и потом разбираетесь, что за кнопка породила событие и на основе этого решаете, что делать дальше, то кнопкам и не нужны собственные хендлеры. Это и есть та централизация, о которой говорил Мук. Надо только иметь систему отождествления кнопка-действие. Если отказались от колбэков, то надо либо завести словарь (Dictionary) в котором привязать каждой кнопке нужное действие (если сами действия принципиально разные) или привязать каждой кнопке какой-то параметр, который будет передаваться функции (если действия одинаковые, то есть один метод с разными параметрами).. Либо не заводить Словарь а просто хранить в кнопках этот параметр в поле класса кнопки.

там другие фичи висят.. долго объяснять в общем так надо
ну т.е. как у меня было сделано до этого да?
попробую для разнообразия сделать со словарем еще

Ну нет, у Вас хранился коллбэк, сам метод. Во-первых, это нифига не простой тип Function)) Хранилась ссылка. А здесь предполагается хранить простой тип, uint или String, просто идентификатор. Во-вторых, у Вас нарушался ООП, можно было подсунуть любой метод, и это вызвало бы ошибку, если бы метод не соответствовал правилам - например, требовал аргументов. Типизировать функцию нельзя, а идентификатор - запросто.
Кроме того, если действия одинаковые, например trace("21"), trace("22") и т.п., то можно просто хранить этот параметр (21, 22) в самой кнопке и иметь один метод, который сделает трейс, а не столько же методов, сколько есть кнопок)))). В общем хендлере получаете ссылку на кнопку (target) и спрашиваете у нее этот параметр. Передаете его в метод.