Обнуление при конверсии типов.

[Wolsh]

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

var sprite:Sprite = new MovieClip();
sprite.gotoAndStop(0) // Error, обращение к неопределенному в Спрайт методу gotoAndStop
var mc:MovieClip = sprite as MovieClip;
mc.gotoAndStop(0); // легко, ведь объект действительно мувиклип

Добавлено через 5 минут
В IDE нет ручного механизма для создания спрайтов. Если при создании объекта ручками вписать класс Спрайт, то будет создан спрайт (и у иконки в библиотеке другой цвет будет). Ну а если Вы сами в классе написали, что это спрайт, то чему удивляться? Я бы не удивился, если бы ИДЕ при компиляции автоматически делала спрайты из мувиклипов без таймлайна... Если конечно никто не пытается использовать их в коде как мувиклипы)

[strangedk]

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

он кстати расширяет Sprite, что... является наверное некоторым косячком

Если у ваш класс явно в коде наследник от Sprite, то Flash CS даже в библиотеке этот символ помечает зеленым (а не фиолетовым) цветом.

Сейчас нет возможности попробовать, но подозреваю что подобное Flash CS делает с MovieClip'ами с одним кадром, без класса-предка в коде. Но только как-то по тихому.

[Akopalipsis]

Добавил такой блок проверки:

Так не правильно. Всё что на экране, это наследники DO и по Вашему условию, всё что не MC это DO.
То есть Вы смешиваете и Sprite и Bitmap..

[Fogflasher]

Wolsh, а ведь наверное и заморочки с иерархией всегда должны быть? Ведь можно кастовать вниз, а можно вверх (причем через одного, двух...).
Так как MovieClip наследник Sprite, то кастовать снизу-вверх наверное всегда сопряжено с побочными эффектами. Хотя тут еще надо поразмышлять над вашим примером, да. Сочетание: переменная одного типа (класса) - но создается как экземпляр другого типа (класса) несколько смущает.

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

Akopalipsis, я так полагаю, тут есть два варианта, что нужно считать "правильным".
С точки зрения, если я хочу получить изначальный тип объекта, то это неправильно.
А если я хочу получить кастанутый тип объекта, то выходит что правильно.

Прямого ответа здесь не было, но подозреваю, что помещение объекта в список отобржаения, это автоматический кастинг: mc as Display Object
(кстати, а почему не DisplayObjectContainer, ну да ладно).

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

[Akopalipsis]

это автоматический кастинг: mc as Display Object

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

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

Тут я не могу ответить, я не знаю что такое кастанутый и не понимаю, как Вы можете в собственном коде ошибиться с типами классов.. Если Вам просто проверить является ли этот обьект типом "...", то is, если Вам нужно создавать с нужным типом обьекты, то flash.utils смотрите, если какое то извращение, то интерфейсы. Вроде всё что можно сделать с типами я перечислил.

Добавлено через 14 минут
Вообще, если Вы не знаете какой будет тип, но уверенны, что он DO и Вы хотите использовать стандартные свойства, то можно вот так -

var object:DisplayObject=target;

[in4core]

Akopalipsis - do зарезервированное слово. Поэтому ВОТ-ТАК нельзя

[Akopalipsis]

in4core Спасибо! Не знал.. хотя сейчас вспоминаю, то есть do..while..

[Wolsh]

Хотя тут еще надо поразмышлять над вашим примером, да.

Размышляйте. У Вас такая каша в голове, что трудно даже отвечать что-то вразумительное, ибо невозможно сходу понять, что и как Вы себе понимаете.
Смысл переменной в чем? В том, что она может менять свое значение в рантайме. Это значит, что компилятор не может знать, какие ЗНАЧЕНИЯ она будет принимать в процессе воспроизведения ролика. Значение — это [ссылка на] область памяти, в рантайме. Компилятор не в курсе, и не может ничего проверить и предотвратить ошибку. Компилятор/код работает не с областями памяти, а с переменными. Этакими абстракциями, представляющими будущий "живой" объект в рантайме. У переменных есть только одно свойство: Тип. И компилятор рассматривает Тип как нечто строгое и незыблемое. Он, естесственно, не может знать, что в переменную типа Спрайт передадут именно МувиКлип (из моего примера конечно это видно, но переменные могут быть параметрами функции, и кто и что передаст в рантайме в эту функцию, никакой супермодный компилятор знать не может). Компилятор проверяет код; и в коде для него есть только данный Тип, указанный в объявлении переменной. Он и в мыслях не допускает, что Спрайт может оказаться МувиКлипом. Это раз.
Наследование называется расширением не просто так. Наследуя какой-то Класс, Вы его расширяете, добавляя новые свойства и методы, которых в суперклассе не было вообще. Например есть суперкласс Транспорт, а Вы создаете расширяющий класс Зенитка. Тут есть некоторый нюанс русского языка — нам кажется что Зенитка не "шире", а наоборот "уже" чем понятие "Транспорт вообще". Можно использовать понятия "абстрактный класс Транспорт" и "конкретный класс Зенитка". А под "расширением" понимается именно увеличение числа "членов класса" — методов и свойств. Класс становится больше, шире. У Зенитки ко всем свойствам Транспорта добавляются конкретные свойства Зенитки — количество стволов, дальнобойность, скорострельность, стрелок, кол-во снарядов, и методы типа стрелять().
Так вот, Вы можете хранить ссылку на зенитку в переменной типа Транспорт, потому что Зенитка является Транспортом. Одновременно. Она И транспорт, И зенитка. Вы можете вызывать у объекта Зенитка все методы и свойства Транспорта, поэтому она может играть роль Транспорта.
Но НЕ наоборот. Вы НЕ можете хранить в переменной типа Зенитка обычный Транспорт, потому что он НЕ может играть роль зенитки — у него нет методов и свойств конкретного класса Зенитка. Это два.
Спрайт наследует (расширяет) Контейнер, тот расширяет ИнтерактивОбжект, а ИО расширяет ДисплейОбжект, который расширяет EventDispatcher и наконец простой Обжект. Следовательно Спрайт содержит все эти типы, и может играть роль любого из них. МувиКлип расширяет Спрайт, и тоже может использоваться как любой класс из этой цепочки. Но ни один класс из этой цепочки не может использоваться ВМЕСТО МувиКлипа.
Когда в приемнике функции Вы создаете переменную с общим типом DosplayObject, это означает, что в функцию может быть отдан ЛЮБОЙ наследник ДО — Битмап, Мувиклип, Шейп, ТекстФилд и тп. Но функция будет рассматривать объект только как ДО, ничего не зная о его расширенных свойствах. Чтобы получить к ним доступ, надо кастовать объект к нужному типу. Это происходит в рантайме, где собственно и существует объект. Для компилятора же есть только тип переменной, в которую его записали, а о конкретном типе объекта он ничего не знает. Поэтому используется механизм проверки is, или кастинг as. В результате кастинга Вы должны создать НОВУЮ переменную уже с конкретным типом, и далее компилятор сможет спокойно с ней работать. Но в рантайме, естественно, тип может не совпасть, если передали ТекстФилд, а кастуем к Битмап, кастинг выдаст нулл. Обработать эту ситуацию проверкой результата кастинга — новой переменной — Ваша забота. Кастинг просто более "демократичен" чем конверсия, не кидается сразу Ошибкой (потому что там нет никакой ошибки по смыслу). У Вас в любом случае получается создать переменную нужного типа, вот только ее значение может оказаться null, как если бы написали просто var s:Sprite; как часто и делают совершенно сознательно.

[Fogflasher]

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

Хотел еще кое-что уточнить. Вот например, если в изначальном примере, тип параметра метода оставить без указания чего либо:

public static function playInto(mc):void

То внутри этого метода срабатывает условие:

if (mc is DisplayObject)
{
				trace("is DisplayObject");
}

При этом, ни "if is Sprite", ни "if is MovieClip" не срабатывают.

Я говорю именно о mc, то есть ни о каких дополнительных локальных переменных метода речь не идет.
Выходит, даже если нигде нет ни кастинга, ни конверсии, он почему-то "превращается" в DisplayObject.

Если я все правильно понял в вашем последнем камменте, такого не должно быть.
Если объект в метод подан как Sprite (хотя есть вероятность, что это все-таки MovieClip, в силу описанного выше двуликого косяка), то он и должен внутри метода определятся как Sprite, а это не так.

Возможно, тут еще влияют дополнительные ньюансы:
1. Этот mc, не добавляется программно изначально, он имеет инстанс-нэйм внутри "основного мувиклипа" в библиотеке, и добавляется в дисплэй лист автоматически, во время добавления туда этого "основного мувиклипа".

2. Может в IDE есть специфика, связанная с библиотечными объектами, которой нет в Builder'e.

[Wolsh]

Я говорю именно о mc, то есть ни о каких дополнительных локальных переменных метода речь не идет.

Именно о них речь и идет. То, что Вы отключили компилятору строгий режим и он позволяет Вам не указывать Тип переменной в параметре, не означает, что это не локальная переменная метода О__о
Просто компилятор укажет ее тип как :*

Выходит, даже если нигде нет ни кастинга, ни конверсии, он почему-то "превращается" в DisplayObject.

Передаваемый ОБЪЕКТ является ДисплейОбжектом. Этого не может изменить ни кастинг, ни конверсия.

var s:Sprite = new MovieClip();
trace(s is MovieClip);

Если объект в метод подан как Sprite

Объект "подан" как он есть. Он может быть "принят" в переменную супертипа, да. Сотый раз повторяю, с объектом НИЧЕГО НЕ ПРОИСХОДИТ. Объект — не переменная. Переменная — не объект.

При этом, ни "if is Sprite", ни "if is MovieClip" не срабатывают.

Есть еще Shape. Bitmap. TextField. SimpleButton. Все перечислять? Они все — is DisplayObject.