-- THE END --
Потому что дальше будет только срач..

Все же есть. Возьми какой-нибудь абстрактный класс который использует стат. ссылку на Stage и перемести в другой проект. Придется убирать во всех подобных классах это обращение и затем своими средствами находить Stage. Ну или в новом проекте так же делать стат. ссылку и затем все равно бежать и переименовывать все обращения, так как главный класс называется по другому и т.п.

чем не решение проблемы? мы можем подписаться на ивенты стейджа и не только в любом месте проекта и в тоже время у нас есть контроль и список обьектов которые на них подписаны. если сильно заела паранойа то можно при желании расширить метод addCustomEventListener занося обьекты еще в какой то коллекшн.
З.Ы. если у кого то есть более хорошее решение то тоже хотелось бы взглянуть.

toFL, rак часто тебе приходится переносить специфические классы от одного проекта в другой?
Мне вообще не приходится. Так что это не аргумент. Второе,
А причем тут главный класс? Есть отдельный класс для хранения статических ссылок, который так же можно перетачить и ноу проблем.

Да? ОК, если связанности нет, то каким образом, используя статическую ссылку на stage, не тащить с собой класс-холдер (он же main в вашем понимании)?
Есть такое понятие, как повторное использование кода, конкретный класс из вашего проекта может понадобиться в другом месте. Так вот из-за связанности, ваш код невозможно повторно использовать.

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

Все обращения можно переименовать одним Find and Replace в редакторе.

И кстати, это уже придирки

Да чего уж там, можно и любой проект целиком в одном классе написать. Все пучком ))

Нет. Чтобы было понятно, он у меня называется Globals
Там по-мимо ссылки на стейдж хранятся константы перевода градусов в радианы и наоборот, и еще много всяких полезных штук. Перетащить этот класс в другой проект так же можно запросто.
Я говорил про специфические классы. Если класс действительно может быть применен (в неизменном виде) в другом проекте, то можно и подписать его на Event.ADDED_TO_STAGE. А если я уверен, что нигде его использовать не буду, то это все просто лишняя писанина

Мне нужен только класс X, зачем мне Globals*и весь этот цирк с клоунами с собой тащить?
Вам надо в автосалоне комплектации подбирать, чтобы подстаканник требовал наличия автокорректора фар и сетки в багажнике, которая в свою очередь есть только в люкс-комплектации. Далеко пойдёте.

etc, я уже сказал, где это удобнее применять.

Идиотизм.

etc. - На личности не стоит переходить, это уже низко.

А если твой X используется собственные события E? Все равно же потащишь.
Хочешь не хочешь, а от связанности тебе не уйти.

Так можно до бесконечности.

goodguy, где-то тут была ссылка на стадии развития программиста. Судя по вашим аргументам вы на стадии синглтона.
Абсолютно согласен с etc. Статике место только там, где она нужна, а не везде, где ни попади, где можно обойтись без нее.
звучит коряво, но подробней объяснять - создавать очередной холивар

Собственные события не тащут за собой ничего лишнего, это нормальные составляющие, которые используются на 100% конкретно в X и связаны непосредственно с ним.

Я против того, чтобы тащить за собой функции вычисления углов, если мне нужен клавиатурный контроллер.

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

Научитесь читать, а не брызгать слюной в монитор ;)
Я никого не призываю использовать этот подход, и более того, сам не использую его всегда и везде. Но и ни от кого не увидел сколько-нибудь серьезных аргументов против.
У меня ссылка на сцену в классах часто создается так:
Любой редактор кода, сможет при желании автоматически заменить _stage на stage за доли секунды, а эту строчку можно удалить и добавить слушатель добавления на сцену (разведя дополнительную грязь в коде). Ничего невозможного не вижу, если уж на то пошло.

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

Я обычно протягиваю. Статики вообще не люблю.

Ты имеешь ввиду конфиг? Таковой максимум будет доступен для основных контроллеров или передаваться им по линку. Другим одноклеточным доступа нет ни в каком виде.
А stage так вообще только протягивать, где это необходимо (опять же, дай б-г для пары контроллеров понадобится). А там, где нет необходимости, там и статик не нужен.

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

а чем он плох...если вывалилась ошибка - ты ищещь ее там где она вывалилась и тебе очевидно откуда ноги растут. а в случае со статиком - пойди его найди где и кто определил значение свойства в нем (в случае со стейджем определенном в мейне - это скорее частный случай). как системный подход - ститик - зло, ИМХО, ессно.

Значит, каждый класс на пути к конечному, будет обрастать ненужным ему функционалом?

Добавлено через 2 минуты
Ничего подобного. Если данные используются во многих местах, то не важно через статик его поменяли или же обратным протяжке путем. И если кто-то поменял, то все кто его используют, должны данные обновить, через весь путь протяжки. Но речь шла о константах.

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

И почему то, что для создателей AS3 очевидно, здесь нужно повторно пояснять людям, основной аргумент которых — лишь собственное мнение. В AS3 доступ к stage построен на резонном убеждении, что он в подавляющем большинстве случаев нужен только тем объектам, которые висят на экране. В остальных (исключительных) случаях разумнее передавать его ссылкой.

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

п.с. Какие у нас нервные флешеры ) Ни в одной теме я еще не получал такого количества минусов :D

Здесь идет изобретение колеса. Не обращайте внимание )

о, да..пример из потенциальных недр кода некоего икс класса:

или не бывает ни у вас ни у тех, кто(возможно) пользует ваши наработки/код?

cleptoman, такой вариант вообще исключен. Даже нет смысла проверять null стейдж или нет. Если ссылка записалась в главном классе, как она вдруг может стать null? Экземпляр главного класса никуда не удаляется

goodguy

Просто уже появились желающие внести свою лепту в разговор, не обременяя себя, перечитать все ранее сказанное

А если главный класс, во время записи ссылки, не был в дисплей листе? о_О

Капец.. i.o. я для кого писал посты на предыдущей странице?
Ссылка записывается уже после добавления его в дисплей лист. В главном классе есть Event.ADDED_TO_STAGE
Зачем громоздить такие конструкции в каждом классе, которому нужен доступ на сцену?
Это загрязняет код.

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

Могу я попросить составить список объектов приложения, навскидку, которые не являются DisplayObject (или являются, но не добавлены в список отображения), и которым при этом необходим доступ именно к Stage?

Zebestov, нет, я об этом говорил раньше. Тут уже всю идею исказили

Разве это разумнее, нежели просто получить его как раз из "статики"?

Да, и плюс сам процесс "протягивания" не загадит код?

Это ты про контроллер клавиатуры и про модальные окошки-алерты? Другими словами один пример из жизни и один пример кривой реализации. Маловато этого для оправдания статической ссылки на stage.

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

Скажем так, есть статическая ссылка на стейдж, она не может быть null.
Тут говорили про связанность объектов (в общем-то единственный аргумент против использования такого подхода). Этого тоже маловато, чтобы поливать грязью такой подход.
После таких фраз неплохо бы дописывать ИМХО.

Да какая связность? Есть класс, есть у него свойства-параметры (через конструктор они передаются или инъекциями - не важно) ты рассматриваешь логику класса только по этим параметрам. Юнит тесты тоже только по этим параметрам. Я могу тестировать отдельный класс, как отдельную сущность почти всегда.