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

[ShadowsInRain]

-De-, эти проблемы притянуты за уши. Если закрыть глаза на реализацию отношений между объектами, АС3 отличается от "взрослых" языков только способом вывода на экран. Все перечисленные проблемы уже решены множеством способов в мириаде выпущенных нативных и не очень нативных игр.
На счёт GetArrayInt и прочего. Вкратце, суть в том, что нет ссылок, есть только числа (uint), которые обозначают какой-то объект. И вот по этим uint'ам нужно совершать все операции.
На счёт игр на флеше. Захожу я, например, на арморгеймс (ссылка), смотрю, сколько раз играли в топовые игры, и слюна автоматически выделяется. .........D: Я изучаю АС3 не для того, чтобы всю жизнь делать унылые баннеры.)

[expl]

expl, какие достойные внимания игры вы знаете? В скольких из них использовался MVC, кроме менюшек? =)

Почти все игры уровня фермы и выше на ВКонтакте, о процессе разработки которых я так или иначе вкурсе - используют MVC в том или ином виде. Некоторые PureMVC (причин последнему не понимаю до сих пор - имхо только палки в колеса вставляет - но многим нравится)

Ды даже когда игру "морской бой" или какие-нибудь "Lines" пишешь - ты же не хранишь и не обрабатываешь данные в спрайтах? Спрайт убрали со сцены не вовремя ради эффектного появления - все досвидос данным. У тебя модель есть, которая хранит карту игры, есть контроллер, который обрабатывает действия пользователя в зависимости от состояния игры.

[КорДум]

какие достойные внимания игры вы знаете? В скольких из них использовался MVC, кроме менюшек? =)

-De-, атата! А TimeZero?

[expl]

На счёт GetArrayInt и прочего. Вкратце, суть в том, что нет ссылок, есть только числа (uint), которые обозначают какой-то объект. И вот по этим uint'ам нужно совершать все операции.

ShadowsInRain, по-моему с тем же успехом можно везде вместо объекта тягать ссылку:

public class UnittLink
{
    public var unit:Unit;
}
 
...
if (link.unit != null)
{
   // действия с link.unit
}

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

Не удобнее ли это чем помнить что из какого хранилища по какому айдишнику достать?
(если не брать во внимание вопросы производительности и создания кучи классов-ссылок или отказа от типизации - генериков то нет)

Или какое-то преимущество упущено?

[ShadowsInRain]

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

[Котяра]

Сообщение от ShadowsInRain

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

Сударь - у вас каша в голове.
В моём тёплом ламповом мире не должно быть никаких взаимодействий соседей с соседями - это глупость несусветная и нарушение первого закона термодинамики программирования - "надо знать как можно меньше" или "меньше знаешь - лучше спишь". Чем меньше связей - тем лучше. И никто не навязывал мне иерархию и DisplayObject тоже ни причём.
В общем проблемы никакой нет. Есть незначительное неудобство при выборе неправильной архитектуры.

[-De-]

expl, КорДум, не, посоны, я не с вами, мне ближе
http://en.wikipedia.org/wiki/List_of...video_games#PC
Ну хоть одна из тех? Да, неизвестно, что там, но вот 0 упоминаний про MVC с ними. По-моему, дела обстоят примерно так. Ну т.е., особая, уличная MVC. Render/Update - две разные функции, контроллер один на всё приложение (что с мышой и клавой говорит, если спросят). Для управляемых AI тварей разве что сделают ещё контроллер. И всё это в одном классе. Так на C++ мы и пишем, да =)
И почему убирают спрайт не вовремя и как при этом происходит досвидос данным? Левел наследует спрайт - не такое плохое решение. Примерно так и пишу (вернее писал, сейчас на работе С++, дома рендер всего в одну битмапу и несерьёзно). У меня, правда, свой спрайт был, который если я не извращался и не дёргал graphics (что редко) - отлично переживёт переход на Molehill. А вам при переходе на Molehill нужно будет править вашу кучу вьюх? =)
PS: UnittLink по сути ссылка на ссылку =)
PPS: ой, оффтоп, всех люблю, но больше тут не пишу.

[mikhailk]

Спрайт убрали со сцены не вовремя ради эффектного появления - все досвидос данным.

Ну, сам по себе метод removeChild данные не удаляет. Это так, без заявки на дискуссию.


Что касается вопроса автора - на мой взгляд, именно этой проблемы нет. Т.е., есть другие (например, та же производительность при визуализации локации с большим количеством анимированных объектов), в ходе решения которых по-любому придется писать ремуверы/деструкторы к своим объектам. Со ссылками тоже ничего волшебного нет. Пишешь addEventListener - тут же пиши removeEventListener.

А вообще, интересно посмотреть, что получится у автра, если он решил сразу начинать с "нетривиального" приложения. Предвижу основательный рефакторинг на последнем этапе разработки приложения.

[ShadowsInRain]

Сообщение от Котяра

не должно быть никаких взаимодействий соседей с соседями

Раскажите это Ромеро и Кармаку, например.

Сообщение от mikhailk

Что касается вопроса автора - на мой взгляд, именно этой проблемы нет.

Да ладно? Ну и как же однозначно удалить объект средствами языка?

Сообщение от mikhailk

А вообще, интересно посмотреть, что получится у автра, если он решил сразу начинать с "нетривиального" приложения.

У меня нет выбора — начать с простого, или сразу взяться за сложное. У меня есть выбор — решить задачу средствами флеш и АС3, или вернутся к нативному решению на С++.

[КорДум]

ShadowsInRain, покажите лучше Ромеро и Кармаку вот эту ссылку: http://ru.wikipedia.org/wiki/Инкапсу...ограммирование)

не должно быть никаких взаимодействий соседей с соседями

Так реализовывается правильная фабрика. Или даже не так: фабрика вообще.