|
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Никто никуда никогда и никак не трансмутирует. Сам по себе объект это область памяти с данными, и он остается таким как есть, всегда одного своего типа. Другие типы могут быть только у переменных, хранящих ссылки. Если Вы объявили тип переменной как Спрайт, она будет "выглядеть" как Спрайт. Если Вы засунете в нее ссылку на МувиКлип, никакой ошибки итак не будет. Просто обращаясь к этой переменной, Вы будете иметь доступ только к свойствам и методам Спрайта, а специфические свойства и методы Мувиклипа (а тем более ваших экспериментов по расширению) доступны не будут. Однако, Вы всегда можете кастануть этот объект обратно в МувиКлип или кастомный наследник мувиклипа, используя ссылку в той же переменной. То есть
var sprite:Sprite = new MovieClip(); sprite.gotoAndStop(0) // Error, обращение к неопределенному в Спрайт методу gotoAndStop var mc:MovieClip = sprite as MovieClip; mc.gotoAndStop(0); // легко, ведь объект действительно мувиклип В IDE нет ручного механизма для создания спрайтов. Если при создании объекта ручками вписать класс Спрайт, то будет создан спрайт (и у иконки в библиотеке другой цвет будет). Ну а если Вы сами в классе написали, что это спрайт, то чему удивляться? Я бы не удивился, если бы ИДЕ при компиляции автоматически делала спрайты из мувиклипов без таймлайна... Если конечно никто не пытается использовать их в коде как мувиклипы)
__________________
Reality.getBounds(this); |
|
|||||
Цитата:
Сейчас нет возможности попробовать, но подозреваю что подобное Flash CS делает с MovieClip'ами с одним кадром, без класса-предка в коде. Но только как-то по тихому.
__________________
adobe AS3 manual |
|
|||||
Banned
[+4 24.02.14]
[+4 07.11.13] [+ 13.03.14] Регистрация: Mar 2013
Сообщений: 1,864
|
Цитата:
То есть Вы смешиваете и Sprite и Bitmap.. |
|
|||||
Регистрация: Mar 2013
Сообщений: 290
|
Wolsh, а ведь наверное и заморочки с иерархией всегда должны быть? Ведь можно кастовать вниз, а можно вверх (причем через одного, двух...).
Так как MovieClip наследник Sprite, то кастовать снизу-вверх наверное всегда сопряжено с побочными эффектами. Хотя тут еще надо поразмышлять над вашим примером, да. Сочетание: переменная одного типа (класса) - но создается как экземпляр другого типа (класса) несколько смущает. strangedk, ну вот в моем портабельном флэше ничего зелененьким не подсвечивается. Даже если в галках явно вписать Sprite. Надо бы перейти на современную версию, да всё как-то не cоберусь, лол. Akopalipsis, я так полагаю, тут есть два варианта, что нужно считать "правильным". С точки зрения, если я хочу получить изначальный тип объекта, то это неправильно. А если я хочу получить кастанутый тип объекта, то выходит что правильно. Прямого ответа здесь не было, но подозреваю, что помещение объекта в список отобржаения, это автоматический кастинг: mc as Display Object (кстати, а почему не DisplayObjectContainer, ну да ладно). Но как быть с первым случаем, который был бы по вашему правильный. Какой для этого код нужен, чтобы некастанутый тип вычислить? |
|
|||||
Banned
[+4 24.02.14]
[+4 07.11.13] [+ 13.03.14] Регистрация: Mar 2013
Сообщений: 1,864
|
Цитата:
Цитата:
Добавлено через 14 минут Вообще, если Вы не знаете какой будет тип, но уверенны, что он DO и Вы хотите использовать стандартные свойства, то можно вот так - Последний раз редактировалось Akopalipsis; 10.12.2013 в 18:22. |
|
|||||
Banned
[+4 24.02.14]
[+4 07.11.13] [+ 13.03.14] Регистрация: Mar 2013
Сообщений: 1,864
|
in4core Спасибо! Не знал.. хотя сейчас вспоминаю, то есть do..while..
|
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Цитата:
Смысл переменной в чем? В том, что она может менять свое значение в рантайме. Это значит, что компилятор не может знать, какие ЗНАЧЕНИЯ она будет принимать в процессе воспроизведения ролика. Значение — это [ссылка на] область памяти, в рантайме. Компилятор не в курсе, и не может ничего проверить и предотвратить ошибку. Компилятор/код работает не с областями памяти, а с переменными. Этакими абстракциями, представляющими будущий "живой" объект в рантайме. У переменных есть только одно свойство: Тип. И компилятор рассматривает Тип как нечто строгое и незыблемое. Он, естесственно, не может знать, что в переменную типа Спрайт передадут именно МувиКлип (из моего примера конечно это видно, но переменные могут быть параметрами функции, и кто и что передаст в рантайме в эту функцию, никакой супермодный компилятор знать не может). Компилятор проверяет код; и в коде для него есть только данный Тип, указанный в объявлении переменной. Он и в мыслях не допускает, что Спрайт может оказаться МувиКлипом. Это раз. Наследование называется расширением не просто так. Наследуя какой-то Класс, Вы его расширяете, добавляя новые свойства и методы, которых в суперклассе не было вообще. Например есть суперкласс Транспорт, а Вы создаете расширяющий класс Зенитка. Тут есть некоторый нюанс русского языка — нам кажется что Зенитка не "шире", а наоборот "уже" чем понятие "Транспорт вообще". Можно использовать понятия "абстрактный класс Транспорт" и "конкретный класс Зенитка". А под "расширением" понимается именно увеличение числа "членов класса" — методов и свойств. Класс становится больше, шире. У Зенитки ко всем свойствам Транспорта добавляются конкретные свойства Зенитки — количество стволов, дальнобойность, скорострельность, стрелок, кол-во снарядов, и методы типа стрелять(). Так вот, Вы можете хранить ссылку на зенитку в переменной типа Транспорт, потому что Зенитка является Транспортом. Одновременно. Она И транспорт, И зенитка. Вы можете вызывать у объекта Зенитка все методы и свойства Транспорта, поэтому она может играть роль Транспорта. Но НЕ наоборот. Вы НЕ можете хранить в переменной типа Зенитка обычный Транспорт, потому что он НЕ может играть роль зенитки — у него нет методов и свойств конкретного класса Зенитка. Это два. Спрайт наследует (расширяет) Контейнер, тот расширяет ИнтерактивОбжект, а ИО расширяет ДисплейОбжект, который расширяет EventDispatcher и наконец простой Обжект. Следовательно Спрайт содержит все эти типы, и может играть роль любого из них. МувиКлип расширяет Спрайт, и тоже может использоваться как любой класс из этой цепочки. Но ни один класс из этой цепочки не может использоваться ВМЕСТО МувиКлипа. Когда в приемнике функции Вы создаете переменную с общим типом DosplayObject, это означает, что в функцию может быть отдан ЛЮБОЙ наследник ДО — Битмап, Мувиклип, Шейп, ТекстФилд и тп. Но функция будет рассматривать объект только как ДО, ничего не зная о его расширенных свойствах. Чтобы получить к ним доступ, надо кастовать объект к нужному типу. Это происходит в рантайме, где собственно и существует объект. Для компилятора же есть только тип переменной, в которую его записали, а о конкретном типе объекта он ничего не знает. Поэтому используется механизм проверки is, или кастинг as. В результате кастинга Вы должны создать НОВУЮ переменную уже с конкретным типом, и далее компилятор сможет спокойно с ней работать. Но в рантайме, естественно, тип может не совпасть, если передали ТекстФилд, а кастуем к Битмап, кастинг выдаст нулл. Обработать эту ситуацию проверкой результата кастинга — новой переменной — Ваша забота. Кастинг просто более "демократичен" чем конверсия, не кидается сразу Ошибкой (потому что там нет никакой ошибки по смыслу). У Вас в любом случае получается создать переменную нужного типа, вот только ее значение может оказаться null, как если бы написали просто var s:Sprite; как часто и делают совершенно сознательно.
__________________
Reality.getBounds(this); |
|
|||||
Регистрация: Mar 2013
Сообщений: 290
|
Спасибо, многие элементы мозайки я вобщем так и представлял, но теперь картинка более целостно выглядит.
Просто архитектура моего проекта-эксперимента достаточно накручена, что усложняет понимание. Хотел еще кое-что уточнить. Вот например, если в изначальном примере, тип параметра метода оставить без указания чего либо: То внутри этого метода срабатывает условие: При этом, ни "if is Sprite", ни "if is MovieClip" не срабатывают. Я говорю именно о mc, то есть ни о каких дополнительных локальных переменных метода речь не идет. Выходит, даже если нигде нет ни кастинга, ни конверсии, он почему-то "превращается" в DisplayObject. Если я все правильно понял в вашем последнем камменте, такого не должно быть. Если объект в метод подан как Sprite (хотя есть вероятность, что это все-таки MovieClip, в силу описанного выше двуликого косяка), то он и должен внутри метода определятся как Sprite, а это не так. Возможно, тут еще влияют дополнительные ньюансы: 1. Этот mc, не добавляется программно изначально, он имеет инстанс-нэйм внутри "основного мувиклипа" в библиотеке, и добавляется в дисплэй лист автоматически, во время добавления туда этого "основного мувиклипа". 2. Может в IDE есть специфика, связанная с библиотечными объектами, которой нет в Builder'e. Последний раз редактировалось Fogflasher; 12.12.2013 в 12:55. |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Цитата:
Просто компилятор укажет ее тип как :* Цитата:
Цитата:
Цитата:
__________________
Reality.getBounds(this); |
Часовой пояс GMT +4, время: 22:43. |
|
« Предыдущая тема | Следующая тема » |
Теги |
конверсия типов |
Опции темы | |
Опции просмотра | |
|
|