обращение сразу ко всем экземплярам определенного класса

[mayakwd]

подобные тесты не дают никаких реальных данных B-)
тем более глубина вложенности у вас равна единице =)

[i.o.]

вам двести тысяч детей о чем-то говорит? Это сделано с учетом того, что в реальности даже во всем древе сцены столько детей никогда не будет. Но даже при такой тяжести все про все отнимает 35 мс. С рекурсивным проходом в два раза медленнее не станет, поверьте.
Можете стоять на своем, мне до этого дела нет.
Вообще, рекоммендую поинтересоваться у автора - ему это для авариума с рыбкой нужно?

[passertm]

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

у меня только один вопрос. почему

for(var i=0; i<numChildren;i++)
if ( !(getChildAt(i) is MyClass) ) continue;
else{обработать getChildAt(i) }

а не

for(var i=0; i<numChildren;i++)
if (getChildAt(i) is MyClass ) {
обработать getChildAt(i) 
}

))))))

Добавлено через 11 минут
тьфу. я чето только первую страницу прочитал подумал на этом и остановились )))))
200 тысяч за 35 милли секунд это бычтро. очень даже по моему. не ожидал

[Котяра]

ну вообще я как и tanatix советую помещать объекты в массив при создании, без всяких статиков итп...
типа так:

var enemy:Enemy = new Enemy();
this.enemyList.push(enemy);

всё. нужны враги - обходим врагов, нужны призы - обходим призы.

[f.g.programmer]

тьфу. я чето только первую страницу прочитал подумал на этом и остановились

Я тоже И мой комментарий оказался очень похож на комментарий gloomyBrain вначале второй страницы.
Это недостаток дизайна. Было бы удобно, если бы под последним комментарием была достаточно заметная кнопка "СЛЕДУЮЩАЯ СТРАНИЦА", если такая есть.

[gloomyBrain]

Задача:

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

Решение i.o.

Пройтись по каждому экземпляру и проверить, является ли он наследником определенного класса, с помощью оператора is

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

Добавка от passertm:

большой минус возможность утечьки памяти ведь при удалении обьекта отовсюду на него еще останется ссылка из храниша

Если у объекта есть метод destroy() или у класса есть статический метод removeInstance() (оба метода могут быть private и вызываться по событиям REMOVED_FROM_STAGE), то вопрос снимается автоматически. Говоря про утечки памяти - удаление элемента массива не есть трудоемкая операция, равно как и удаление со сцены. Так что аргумент в расчет не принимается.

Мнение mayakwd:

я считаю что код должен быть продуктивным

Полностью согласен. Равно как и с тем, что код должен описывать те и только те действия, которые необходимы для решения поставленной задачи.

[chabapok]

Вы тут спорите ни о чем. Главное - идея. Идеи подкинули -- дальше пускай топикстартер сам решает что ему нужно.

может ему нужно перебирать эти экземпляры 1 раз при запуске. А может в каждом событии ENTER_FRAME. Требования к оптимизации, естественно разные.

[passertm]

Сообщение от f.g.programmer

Это недостаток дизайна. Было бы удобно, если бы под последним комментарием была достаточно заметная кнопка "СЛЕДУЮЩАЯ СТРАНИЦА", если такая есть.

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

Добавлено через 25 часов 28 минут

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

Если у объекта есть метод destroy() или у класса есть статический метод removeInstance() (оба метода могут быть private и вызываться по событиям REMOVED_FROM_STAGE), то вопрос снимается автоматически. Говоря про утечки памяти - удаление элемента массива не есть трудоемкая операция, равно как и удаление со сцены. Так что аргумент в расчет не принимается.

вот в этом и есть беда. в кажужейся простоте реализации. к примеру после такой реализации. обьект может быть добавлен на сцену а потом удален и потом вновь добавлен и вот дела. всеми подобным обьектами на сцене производится действия а с одим нет. убиться можно пока найдешь причину если обьектов больше 1000(т.к. удаление и добавление могло произойти на пол часа до того как что то пойдет не так).

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

[alatar]

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

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

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

Это уже будет кривизна конкретной реализации, сам метод (сбор ссылок на экземпляры) предельно прост, накосячить в нем, это надо постараться.

[gloomyBrain]

накосячить в нем, это надо постараться

Вот я тоже так думаю. Там отлаживать-то 3 (ну ладно - 4) строчки кода =)