flash/9.0/ActionScriptLangRefV3/operators.html

adbe_paul — 2008-05-06T13:35:54

@No nickname:
The reason the second and third versions both give true is because the object that's being tested is indeed a Sprite.

Obviously it's being cast (using two different techniques) as a DisplayObject instance -- which is just fine, because every Sprite is also a DisplayObject -- but Flash Player still knows that the actual object it's storing in its memory is a Sprite.

To carry the point to an extreme case, consider this code:

var s:Sprite = new Sprite();
var a:Array = [s];
trace("a[0] is Sprite", a[0] is Sprite); // true

In this case, the third line will also trace "true", even though a[0] could theoretically be any type of object (the "return type" of the square bracket operator is Object). So in that line of code the player reads a[0], which at compile time it only knows is an Object. (Basically the add-to-array remove-from-array dance is a fancy way to cast s as an Object.) At run time the player looks at the actual object in memory to find out if it's a Sprite instance.

I guess the point I'm trying to make is that type casting is in some sense a compile time mechanism only (especially in your third line -- in that case it is literally a compile time mechanism only). In those examples, there's really no point to doing the type cast in the second and third lines. It doesn't fundamentally change the nature of the object. Upcasting to a superclass (as you're doing here) doesn't make the subclass functionality somehow disappear. The only reason for casting is when you're retrieving something in a context where you can't guarantee the data type of an object at compile time (such as when you're retrieving the object from an array). So you cast to make the compiler happy. The reason my example works even without casting is because Object is a dynamic class -- so the compiler doesn't do *any* compile-time type checking of Object instances, and leaves all the type checking to run time.

This aspect of type checking is one of the things that makes ActionScript flexible and more "scripting" language-like. A while ago I wrote an article that goes into more detail about data types in ActionScript at compile time and runtime. Maybe you'll find it useful:
http://probertson.com/articles/2005/11/08/actionscript-3-unit-testing-recommended/

flash/9.0/ActionScriptLangRefV3/operators.html

2008-05-05T06:08:36

Hi. Why does the following lines return true, all three of them?

var a:Sprite = new Sprite();
trace(a is Sprite, " = a is Sprite");
trace((a as DisplayObject) is Sprite, " = (a as DisplayObject) is Sprite");
trace(DisplayObject(a) is Sprite, " = DisplayObject(a) is Sprite");

I understand the first returning true, I could even understand the second (strictly from the documentation it's ok to return true, but I think the "as" word is misleading), but I definitely don't understand why the third one is true.

Could some one explain me the exact semantics of those thing?

Thanks,
FaQ

flash/9.0/ActionScriptLangRefV3/operators.html

Joe ... Ward — 2007-10-19T12:46:03

You are correct. The description should emphasize the affect of the conversion a bit more strongly. Note that you can convert the result back to 16bit by bitwise ANDing (&) the NOR result with 0x0000ffff.

LiveDocs Comments - flash - 9.0 - ActionScriptLangRefV3 - operators.html

flash/9.0/ActionScriptLangRefV3/operators.html

flash/9.0/ActionScriptLangRefV3/operators.html

flash/9.0/ActionScriptLangRefV3/operators.html