Вопросы по stage

[me2]

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

Сам по себе getChildByName не вреден. Вреден он в конкретно данном случае, но менее вреден, чем вариант со статическим stage.

Гомерично ржал (уж простите). Обратится к статичному поинтеру или постоянно дёргать метод. Выбор очевиден.
Некие события stage нужны независимо от того, какая иерархическая структура результатирующего класса.
Обычно, опыт и серьёзные проекты отметают возражения на этот счёт

[etc]

RaVeN-Nikma, нельзя, потому что не находящиеся в display list объекты вообще не должны ничего делать. Ссылка на stage у вас будет, подписывайтесь на здоровье, потом отпишитесь точно также.
Однако, если вам наплевать на расход памяти и в вашем коде removeEventListener встречается на порядок реже addEventListener, вы можете пользоваться любым удобным для вас способом.

me2, выбор очевиден, действительно. Для узкомыслящих.

[RaVeN-Nikma]

Однако, если вам наплевать на расход памяти и в вашем коде removeEventListener встречается на порядок реже addEventListener, вы можете пользоваться любым удобным для вас способом.

Если удалять листенеры объекта после его ухода со сцены, то никакого дополнительного расхода памяти не будет, этот момент косвенно касается статичного хранения ссылки на stage, и видимо все возвращается к первоначальному: "кому как удобно", и слово нельзя тут не уместно.

Спасибо за дискуссию

[etc]

Сообщение от RaVeN-Nikma

Если удалять листенеры объекта после его ухода со сцены, то никакого дополнительного расхода памяти не будет, этот момент косвенно касается статичного хранения ссылки на stage, и видимо все возвращается к первоначальному: "кому как удобно", и слово нельзя тут не уместно.

Спасибо за дискуссию

Не возвращается, открытые и доступные всем и вся ссылки на stage — потенциальная недоработка.

[Bgg]

Все можно когда пишешь код один, но когда пишет группа, то статичные объекты, да ещё которые можно изменить - это зло.

[me2]

Мда, и как всегда - куча мусора, ничего дельного. Не знание основ работы display list`a, не умение широко мыслить, не знание "не шаблонных" приёмов программирования.

"потому что не находящиеся в display list объекты вообще не должны ничего делать" - (поржал вторично)

Подытожим - использовать static stage дело правельное и нужное. Желательно указать в main.as

Чистить за собой - это первый класс, обсуждать и указывать на использование removeEventListener - это бред, и так понятно.

Думать что lifetime и interactions объекта привязаны к его видимости в displayList - очередной бред. срочно к санитару.

Носится каждый раз по displayList`у с geChildByName() - за это стрелять в голову. (этож надо... name... так кодили на as2 во фреймах)

К сожалению оппоненты использования static stage проявили высшую степень некомпетентности, не подкрепив весомыми аргументами и доказательствами своё мнение. За сим считаться с ними совершенная бессмыслица.

P.s.
Bgg
это всего лишь вопрос профессионализма. сделай getter на static stage, а в setter`е не позволяй менять, если уже синициализировано.

[RaVeN-Nikma]

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

Все можно когда пишешь код один, но когда пишет группа, то статичные объекты, да ещё которые можно изменить - это зло.

Риторическое отступление:
На что можно изменить public static STAGE:Stage, кроме как на Stage или null, да и зачем его вообще менять, даже работая в команде. Вы же не работаете в кругу врагов, которые так и мечтают из своего класса в main.as в STAGE поставить null, чтобы все сломать )))

Что касается в общем статичных переменных, то тут пожалуй соглашусь.

[etc]

me2, слишком толсто, маловато огня.

[goodguy]

etc, а в что, действительно, плохого в использовании статической ссылки на stage?
У меня статическая ссылка на сцену используется для добавления разных окошек с предупреждениями, которые сами добавляются поверх всего остального, и сами же полностью удаляются при нажатии кнопки подтверждения. Не буду утверждать, что это лучший, или даже один из лучших методов, но он однозначно удобен.
П.с. А во избежание зануления ссылки, можно использовать private static var и назначать ее сеттером, в котором проверять новое значение не валидность

[etc]

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

etc, а в что, действительно, плохого в использовании статической ссылки на stage?

А зачем она? Какой смысл делать stage доступным всем и вся? Надо подписаться события — подпишись после ADDED_TO_STAGE, сохрани локальную ссылку, чтобы потом отписаться, занули и тебя соберет GC. Если это клавиатурный менеджер — передай линк на Stage извне. Меньше связанности, меньше свободного доступа к чему-либо — всё это располагает к неограниченной расширяемости и возможности распиливания проекта на отдельные части, безболезненной замены одной на другую. Это всё та же концепция черного ящика, который замкнут внутри себя и работает внутри себя, не распуская руки туда, куда не нужно. Если ему что-то нужно для работы — это всё должно прийти снаружи. Я уже не говорю про отсутствие конфликтов кода при разработке проекта несколькими людьми, при условии, что они соблюдают концепцию, конечно.

Если завтра придёт очередной джуниор и подпишется в трехстах местах на этот самый статический stage в каком-нибудь вьювере, даже ещё не добавленном на сцену, насоздаёт этих вьюверов «про запас», убирать за ним желания никакого. Лучше он спросит, как сделать правильно, просто уперевшись в отсутствие доступа. И потом будет делать всё правильно.

Статический stage, банально, тащит за собой класс-холдер, а он в свою очередь тащит ещё всякой дребедени за собой.