Форум Flasher.ru - Event-callback-сироты

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - Event-callback-сироты (http://www.flasher.ru/forum/showthread.php?t=119187)

Event-callback-сироты

Я как-то не задумывался про зачистку памяти от событий и их callback-функций. Есть у меня примерно такой код:

Код:

mov.addEventListener(MouseEvent.CLICK, function(e:MouseEvent):void {

  e.currentTarget.parent.removeChild(e.currentTarget);

});

Память загадится или при удалении mov удаляются и все его события и функции-сироты?

P.S. Естественно, если функция имеет свой дом (: я событие удаляю по нормальному перед удалением объекта.

Это уже один из поводов никогда не использовать конструкцию из кода выше.

Нужно подписывать на нормальные функции.

Нужно подписывать не функции, а методы экземпляров класса.

Ну, я примерно так и думал, просто сложно отказать себе в JavaScript-стайл-программировании.
А на поставленный вопрос кто-нибудь ответит? (: Что случится, если всё-таки писать так, как в примере?

Случится запор в памяти.

А если конструкция будет примерно следующая?..

Код:

mov.myNewMethod = function(e:MouseEvent):void {

  this.removeEventListener(MouseEvent.CLICK, this.myNewMethod);

  this.parent.removeChild(this);

}

mov.addEventListener(MouseEvent.CLICK, mov.myNewMethod);

Память не будет страдать нехорошими болезнями? (:

Если сможете отписаться, то не будет.
Но зачем использовать такие кривые конструкции?

Ясно. А что в этих конструкциях кривого?
Не создавать же мне 50 своих классов только для того, чтобы сделать им 50 методов, отнаследовать 50 мувиков от этих классов, чтобы можно было нормально подписаться/отписаться на события.
По моему кривая конструкция - у Гарбаж Коллектора.

1. есть динамические классы.
2. что предпочтительно - вы ведь в любом случае создаете объект класса, так какая вам разница, будете вы создавать объекты типа Sprite или CustomSprite? Я не верю, что нужно 50 разных методов... скорее всего можно обойтись 2-3 разновидностями... ну десятком на крайняк, но их все равно нужно будет написать в таком случае, так что работы ну уж точно не прибавится.

Базовый класс у мувиков в либе тоже можно задать кастомный.

wvxvw
Ну так MovieClip и есть динамический класс. Разница в том, что эти классы нужно будет писать, а тут ррраз и работает. (:
Нужно это для разного рода мелкий мелочей, которые должны сами по себе что-то там поделать и самоуничтожится при некоторых факторах - время, клики и прочие события, порой сложные (когда игрок попрыгнул и подул северный ветер, и т.д.)
Таких мелочей в проекте может набраться и за сотню. Просто некоторые красивости. Писать для каждой такой красивости отдельный класс - это ж сколько неблагодарного труда.

В общем я так понял, что если динамически расширять класс MovieClip и затем отписываться от событий - всё будет ништь. Значит так и буду делать.

Ух... нет... MovieClip тут ни при чем, и вообще, сам факт того, что он динамический, это, по словам разработчиков "дань традиции таймлайн-кодеров". Никакой реальной жизненной необходимости в этом не было.
Если нужно много разных функций в зависимости от ситуации подписывать на какое-то событие, то:
- вам их все равно надо написать! Так написать их в классе удобнее и быстрее. Кроме того, потом удобнее их искать, редактировать и т.п.
- есть еще вариант типа mix-in это когда создается набор функций, а потом, в зависимости от ситуации, эти функции делаются методами объекта. Но чесно говоря, на практике мне не встречались ситуации, когда бы нужно было использовать этот подход, как правило решение "по учебнику" и выглядит красивше, и в последствии не создает проблем.