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

Цель выполнена, так что тему можно считать закрытой, всем спасибо!

Если "обрубок кода" это target.parent.removeChild(target); то лучше бы вам вообще навсегда удалить это из памяти, и уж ни в коем случае не передавать это новичкам.
Примерно об этом вам 2 страницы комментариев написали. Если всё впустую, то да, можно закрывать тему.

Добавлено через 7 часов 9 минут
Можно создать 100500 массивов и наполнить их ссылками на детей, творящих на сцене, что им вздумается. В правильном примере HardCoderа наоборот, ни одного массива нет. Связи между массивами как инструментом и иерархией ответственностей, как основой проектирования, нет вообще никакой.
Если целью было "Заработало!", то грош цена такой цели. Это не цель, это необходимый минимум, отправная точка. Как бы код, который не работает – это не код. Работающий код это норма, а не цель. Здесь на форуме приветствуется желание изучать, то есть учиться писать хороший код. Сделать "заработало", чтобы сдать задание в школе или срубить деньжат – не имеет ничего общего с изучением и повышением уровня. Советую Вам все же разобраться с тем вопросом, который поднял HardCoder. Самоудаляющиеся дети, приказывающие родителям – это муветон. Вы сделали так один раз, и сделаете так в следующий раз. И уже получите привычку делать неправильно. Правда в том, что ситуации, когда флэш-проект состоит из одного классика, крайне редка. И когда вы примените этот прием, а главное – этот подход "дети сами за себя в ответе" – в чем-то сложнее "лопающегося пузырика", рано или поздно – чаще поздно – заметите что земля почему то уходит из-под ног и проект распадается где-то на генетическом уровне, хотя никаких ошибок в коде нет. Это ошибки проектирования. Не прививайте себе эту привычку, от плохих привычек трудно избавляться.

Wolsh , а мне вот интересно твое мнение как раз, вот в таком случае :
Есть статик класс с набором эффектов , каждый эффект один независимый метод, эффект работает на основе битмапДаты
public static function flashEffect(source:DisplayObject , ...rest):void
в методе происходит следующее, зарисовывается соурс в битмапу , происходят всякие манипуляции и т.п. в итоге создается эффект, но чтобы эффект получился сначала надо скрыть соурс, затем показать куски битмапы, а по заверешнию эффекта их удалить. Тоесть в коде будет например следующее
В данном контексте ты бы как делал, или здесь это логично?

Здесь никто не управляет своим родителем, а ссылка на контейнер нужна в любом случае, так что все логично. Единственно, я бы не чайлдил битмапы прямо в контейнер сёрса, а сделал им свой спрайтик.
Вобщем это совсем другая ситуация) Здесь не ребенок говорит родителю, что делать, а некий... воспитатель))

Смысл запрета на управление родителем заключается, на мой взгляд:

1. Вы теряете контроль за состоянием родителя в любой момент времени. Если чилд один - то вроде бы нет проблем, а если их 1000 и более?

2. Создает проблемы при повторном использовании таких чилдов в другой программе. А что если в новой среде требуется контроль за такими объектами со стороны парента? А что если это вообще не ваш парент, то есть кто-то пользуется вашим объектом (напр. в командной разработке)? Переписать можно? Иногда это просто, а иногда проще заново написать...

Поэтому в вашем случае я бы манипулировал объектами из под парента. Т.е. он отдает ДО в обработку, получает и распоряжается результатами работы.

Вообще эта метафора с родителями и детьми не всегда способна хорошо отразить происходящее.
Мне нравится другая – мастер и инструменты. Она не отражает момент создания, но хорошо описывает отношения. Когда "родитель" создает экземпляры, какие-то объекты, он знает, зачем он это делает. Они – инструменты для достижения каких-то целей, выполнения известных мастеру задач. Мастер берет инструмент и что-то с его помощью делает (например, заменяет курсор на свой кастомный). Если мы в такой ситуации добавим инструменту логику, например реагировать на разные типы объектов, оказывающихся под курсором, нам придется построить целую машину общения курсора с окружающим миром. При этом у нас не будет никакого контроля за его поведением, и рано или поздно мы столкнемся с тем, что не можем запретить курсору меняться над объектами определенного типа, если они также соответствуют какому-то условию. Все разнообразие мира придется добавлять и добавлять в курсор, и в какой-то момент окажется, что курсор обрабатывает больше информации, чем все остальное приложение.
Здесь речь не об абстрактной логике – инструмент может быть "умнее" мастера, это нормально (пример: компьютер и оператор). Речь об областях ответственности, о видении картины в целом, знании задачи, "смысла" приложения. Приложение владеет точным знанием всех ситуаций, когда, зачем и на какой вид курсору меняться. Курсор должен только уметь это делать. Он не должен думать, это не его сфера ответственности. Инструмент должен уметь думать только над решением поставленной задачи, иначе нас ждут терминаторы и восстание сайлонов.

Болтать можно сколь угодно долго, у философии нет конца. Правильность кода определяется конкретной ситуацией, когда нужно применить именно это, а не что-то другое.
Я спросил пример, мне его дали да ещё и пояснили, +10 очков опыта.

То что я не дал обратной связи не всегда говорит о непонимании.
Так что Wolsh, можете не переживать, Ваши потуги я принял к сведению. Но и ещё на будущее, любое словесное сообщение пустой звон, если в нём нет практики, в данном случае примера. Слова у двух человек могут иметь разные значения!
Истину приносит только пример/практика/опыт...

PS: Американские программисты никак не могут понять, почему русские при зависании Windows всё время повторяют фразу "Твой кролик написАл" (Your Bunny Wrote)

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

"Соккетный форум" - говорите? Ха...

Добавлено через 8 минут
write(n/r).

Под каждый код своя конструкция, если у вас есть панацея читайте ниже.

Wrote/Write полистайте анг словарь.

Сообщение я написал с любовью. А то что Вы сударь fish_r начали придираться к словам это уже от лукавого.
fish_r и другие, если Вы обладаете истиной в первой и последней инстанции по поводу темы данной дискуссии, а именно панацеи обращения к объектам а так же их удаления, прошу сообщения свои подтверждать кодом

Я тоже написал вам, в таком случае, с любовью. А вы про придирки?

Я не обладаю "истиной и т.д". Но аргументирую свою позицию. Хотите - слушайте, не хотите - не слушайте.
Вообще говоря, и сообщение-то я не вам написал...