ошибка ArgumentError: Error #2025 - Страница 2

in4core · [+4 06.05.14]

Цитата:

Именно это и есть корявая работа. Зачем нужна такая функция вообще? Где она реально может понадобится?

Кость - реально врдяли где, да. Но смотрится лучше чем parent

Парент он как пережиток AS2 - пугает

Цитата:

Под быдлокодерством я подразумевал то, что почему-то вдруг мы не знаем, кто содержит объект и обращаемся к его безликому по сути паренту. Это свидетельствует о том, что работа программы выходит из-под контроля, что чревато проблемами.

Никакого быдлокодерства - только кадры, только хардкор. На самом деле действительно такие вещи частенько бывают, особенно в мелких проектах, они удобны.
Вот к примеру , нарисовал ты в IDE 3 вложенности клипов ( 3 уровня ). И в какой то момент тебе захотелось , чтобы нижний уровень после некой анимации, запускал анимацию верхнего уровня.
Безусловно - есть для этого dispatch , и много других оберток. Но делать их для каждой подобной анимации не всегда оправданно и занимает прилично по времени. Это не логическая составляющая приложения, а лишь анимация, которая ни к чему не принуждает и проблем в будущем никак не создаст образно говоря. - вот тут как раз и выгодно пользоваться быдло-словами дабы не нагромождать код.
И да - что не говори, а Костыльно Ориентированное Программирование - пока что лучший вариант и останется им всегда и для всех за нехваткой времени.
Приведу даже пример на собственном опыте : был недавно проект, задача которого была написать движок игровой, чтобы потом под этот движок собирать аналогичные проекты быстро и удобно. Сделали. Но как ни крути в будущем, в зависимости от игры появляются новые фичи ( анимационные как раз ) или удаляются старые. То есть движок сделать универсальным нельзя для этих мелочей. И чтобы не переписывать часть завязанного функционала, для анимации вполне подходят ЛЮБЫЕ возможные подручные костыли типа setTimeout() и названия функций типа lalala - ничего никому не говорящие и не должны, ибо на логику игр они не влияют никак, а вот анимация уже специфическая.

Akopalipsis · 30.04.2014, 15:18

Цитата:

Но смотрится лучше чем parent

Мне помнится Вы мне советовали получать доступ к stage таким же образом, это по Вашему нормально?
Мне почему-то кажется, что если объекту нужен stage, то лучше явным образом её передавать.

caseyryan · 30.04.2014, 15:57

Цитата:

Мне почему-то кажется, что если объекту нужен stage, то лучше явным образом её передавать.

Нет. Не лучше. Если это дисплей объект (а ссылка на stage есть только у них), то доступ к stage лучше всего получать по Event.ADDED_TO_STAGE, а удалять слушатели со stage по Event.REMOVED_FROM_STAGE

delphic · 02.05.2014, 20:49

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

delphic · 07.05.2014, 14:03

проблема решена

Zebestov · 07.05.2014, 16:16

Цитата:

Сообщение от КорДум

Я не знаю, где вообще может понадобится узнавать, что где-то в пятом колене дисплей листа есть этот ДО

Цитата:

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

Именно это и есть корявая работа. Зачем нужна такая функция вообще? Где она реально может понадобится?

На нативном уровне работы DO — для предотвращения попытки добавить в себя кого-то из вышестоящих родителей, например.