Гарантированное удаление объекта

[zzz7net]

такое ощущение, что в AS3 от AS2 кроме синтаксиса ничего и не осталось.
А по сложности этот скриптовый язык, скоро обгонит такие нескриптовые языки как С+ и Delphi вместе взятые ))
У меня где-то книга по Action Script 2 завалялась - объёмом 1266 страниц. Видимо по AS3 того же автора, будет в нескольких томах.

[Bgg]

И синтаксиса тоже мало осталось. И слава богу.

[-De-]

Если обьект помер, то всем заинтересованным лицам надо об этом сообщить (Кэп).
Вопрос только, как это сделать. Можно слать событие "я помер", все заинтересованные лица на него подписываются, скорбят, паникуют и трут ссылки. Вроде как считается труЪ здесь, но в "больших" играх по-моему такого нет =) Обьект может вызывать сам у заинтересованных лиц метод тварьНичтожнаяСдохла(this). Как по мне - те же яйца вид сбоку. Меньше мутоты с слушателями и событиями, но может иметь последствия вплоть до фатальных, если неаккуратно сделать. Сделать можно по-разному. Ну например завести у обьекта вектор функций, которые он дёрнет при вызове "деструктора".
Ещё можно, например, у обьекта поставить флаг "мёртв"? проверять его когда ни попадя и делать что-нибудь.
Соответственно, ссылки кому ни попадя давать нельзя. Но обычно и не надо.

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

Также ограниченно эффективны слабые ссылки, см. например, выше "во-первых".

Ещё интересно, что за волшебный язык/библиотека, где есть слабые ссылки и автодеструктор.

PS: По-моему, если делаешь игру в основном один - MVC - не нужен.
PPS: Слабые ссылки в AS3 - ключи соответственно созданного Dictionary - читайте справку по нему и вообще гуглите AS3 слабые ссылки/weak references. Есть ещё в addEventListener. Но как для игр - маловато, да. Да и прибьются обьекты только когда GC захочет (дааалеко не сразу, на практике).

[expl]

Ещё интересно, что за волшебный язык/библиотека, где есть слабые ссылки и автодеструктор.

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

PS: По-моему, если делаешь игру в основном один - MVC - не нужен.

Если ты делаешь игру один - тебе не очень нужна одна вещь - система контроля версий (и то с ней приятней, чем архивы с датой в качестве бекапов использовать).
А поддерживать код все равно придется - так что MVC или еще что, а _не_ превращать проект в спагетти-подобный нужно.

[ShadowsInRain]

-De-, если релизить слабую ссылку через индексы / GUID'ы / хендлы (название почти не меняет сути), то никто гарантированно не получит доступ к объекту, если он решил умереть. Гемморой в том, что перед любым использованием объекта придётся проверять его хендл.

validateHandle(m_hVictim);
if(m_hVictim) { ... }

UPD
Хм, а чоо это я. В принципе, в сях/сисях то же самое, нужно слабую ссылку сначала валидировать (залочить), а потом уже работать с ней. Можно и попробовать.

[-De-]

expl, какие достойные внимания игры вы знаете? В скольких из них использовался MVC, кроме менюшек? =)
ShadowsInRain, ну вот "почти мёртв" случай. Т.е. нужен только в недрах графики, для мебели, а везде кроме того надо убить. Или получим +1 класс "умирающая тварь" (а если повезёт, то сколько тварей, +столько классов).
Кстати, а каким волшебным образом функция validateHandle поменяет m_hVictim в произвольном классе? =) С ссылками на ссылки в AS3 тяжко. Или её делать методом всех нужных классов. Можно как-то так:

m_hVictim = validateHandle(m_hVictim);
if(m_hVictim) { ... }

На GUID даже можно не разоряться, просто флаг "жив" сделать полем класса (не будет поиска по массивам/хешам). Тут ещё минус в том, что обьект получается внезапно смертен, что, как мы знаем от классиков, может быть неприятно.
В общем, про систему оповещения заинтересованных лиц советую подумать, она, в чем плюс, может не только для события смерти работать.

[ShadowsInRain]

-De-
Нету в ссылках на ссылки никакой сложности. По крайней мере для меня (эгоизм енабле). Я работал с многократно вложенными массивами, доступ к которым осуществлён полностью через интегральные типы (uint, void*), ибо функциональный интерфейс. Были методы навроде GetArrayInt(arr_Fields, index_field, &arrh_CurrentField), и ничего, всё живы. Единственный важный момент — правильно называть переменные. Да и сейчас разрабатываю функциональный интерфейс, там тоже приходится валидировать каждый входящий параметр, почти как в системном программировании. Напрягает только рутинность.
Насчёт этого одинокого примера с "полумёртвым" объектом. Я не вижу смысл гонять вокруг него воздух. Для этого уже в прошлом веке отработаны паттерны. Создаётся временный объект, который поддерживает анимацию смерти, и удаляется. В этот момент прежний объект может быть уже заспавнен где-то и подбежать, посмотреть на свой труп.

[Котяра]

Не вижу никаких сложностей. мне кажется вы путаете красное с мякгим.
GC он и в африке GC - что в яве, что в С# - объект существует пока есть на него ссылка.
дитю не надо самоубиваться. если вы хотите чтоб объект уничтожался после первого же
delete child - то это плохо.
делать кучу перекрёстных связей - вообще плохая практика. Чем связей меньше тем лучше.
А если связей 1-максимум 2-3, то нет ничего сложного в нужный момент их разрывать.

[ShadowsInRain]

Котяра, сударь, я понимаю, что вам ближе тёплая ламповая иерархия как у DisplayObject. Но в реальном мире бывают явления и на порядок сложнее. Как раз, как в сабже. В моеё задаче загвоздка в том, что есть один родитель, у него куча чайлдов. Причём эти чайлды резвятся в одной большой песочнице, взаимодействуют друг с другом, имеют отношения, могут друг друга запомнить, и так далее. И вот в этом и проявляется проблема жёстких ссылок: они лишают объекты личной свободы. Это именно проблема реализации, которую мне сейчас придётся объезжать на велосипеде. Почему на велосипеде? Потому что АС3 не имеет втроенных слабых ссылок, которыми было бы пользоваться так же удобно, как и сильными, включая статическую типизацию, которая спасла не один миллиард нервных клеток.
UPD
На мой взгляд, АС3 просто таки навязывает иерархию DisplayObject, когда есть дерево, и никаких связей между его ветками. И это очень порочный ход разработчиков. Как будто они забыли(?), что флеш активно используют для игр, а не только для баннеров, мувиков и простых приложений с инпутбоксами.

[-De-]

ShadowsInRain, ключевые слова "в AS3". Аналог GetArrayInt(arr_Fields, index_field, &arrh_CurrentField) на флэше какой? =)
Про полумёртвого - это только один пример (кстати, поздравляю с увеличением кол-ва классов). Не только смерть же может быть причиной. Застанили того пехотинца - не охраняет он уже ничего. НЛО забрало, проведёт опыты и вернёт в целости. В невидимость он ушел.
И вроде ж в яве всё тоже не айс со слабыми ссылками, обнуляются только когда GC захочет, где ж они тогда есть-то хорошие?
PS: до Molehill флэш - это ютуб, и баннеры, да, редко - сайты, а игроделы на нём - извращенцы =)))