this=null?

[Dukobpa3]

Ну задача стояла изнутри самого себя удалить)
Помнится когда-то и у меня была такая задача. Правда что-то давно уже не помню чтоб такая потребность возникала. Может писать научился просто. А так то оно конечно да, лучше делать сверху вниз управление.

[Zebestov]

Задача да. Но мы ж тут вроде уже начали правильные советы давать
И к слову: внутренний "ентерфрейм" работе GC не препятствует.

[Inet_PC]

2. продиспатчить наверх событие "удали
меня"

Получается, чтобы освободить ресурсы нам нужны ресурсы. В c# при запуске выделяется память под 3 ошибки(одна из которых ошибка нехватки памяти)чтобы если ошибка произошла мы могли выкинуть исключение. Так и у вас получается FP потребовалась память он освобождает нужна еще, ну вожможно я утрирую, поправьте если не так.

[expl]

Ну задача стояла изнутри самого себя удалить)

1. Что значить _удалить_?
В С это значить освободить память. В ActionScript это делаем не мы.
В ActionScript не надо ничего удалять - ссылки почистили - объект ушел (может сразу, может через час, может никогда).

2. Но с ненужным объектом надо что-то сделать, чтобы он не жрал ресурсы.
Он жрет
- память
- процессор
Как он жрет память? - просто занимает место, чтобы это побороть надо снести все ссылки на него.
(кстати, подписка метода объекта на событие тоже держит объект в памяти)
Как он жрет процессор? - он подписывается на таймер или ENTER_FRAME, или на другой объект, который диспетчит события и обрабатывает постоянно эти события.
Как бороться с потреблением процессора? - отписывать от всего _внешнего_ и от таймеров/ENTER_FRAME-ов (в документации Adobe это называется "заморозить")
Т.е. объект мы удалить не можем, можем только "заморозить".

Кстати, по этой причине совсем не обязательно отписываться от событий мыши самого объекта.
Объекта нет в списке отображения - значит он в принципе не обрабатывает мышиные события и не жрет проц. А поскольку он подписан на себя, то и в памяти он не задержится.

3. Когда "замораживать" объект и кто это должен делать?
Это уже зависит сугубо от ситуации.
Самый тупой подход для DisplayObject-ов - это подписываться на собственные события ADDED_TO_STAGE и REMOVED_FROM_STAGE. Соответственно в onAddedToStage - РАЗмораживать, в onRemovedFromStage - ЗАмораживать.
Т.е. никаких удалений/созданий - заморозка и разморозка, не осталось ссылок на объект - значит его в принципе тронуть никто не сможет и в свое время будет собран GC, осталась ссылка - значит его кто-то может захотеть добавить, но он заморожен и кроме памяти ничего не жрет. Боитесь за память? - обнулите ссылку.

[Tails]

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