Sprite vs. Movieclip

[Shaedo]

I seem to run into trouble using Sprite instead of a MC when I need to type cast the parent in order to say run a public function or interact with a public variable. As a result I have used a MC even though it can be essentially only one frame. Sprite does not seem to work for this eg

Sprite(this.parent).myPublicFunction();//fail
MovieClip(this.parent).myPublicFunction();//ok

[Krilnon]

The Sprite class is sealed (not dynamic), so the compiler won't let you access any property (or perhaps redundantly mention, any method) that isn't defined by the Sprite class or one of the classes from which Sprite inherits. MovieClip is a dynamic class, so you can access any property, defined or not, and the compiler won't complain.

In the dynamic case, the compiler just sees that it's supposed to access a property of the supplied object given the property's name (a string). It knows that the object is dynamic because of your cast. In the sealed case, the compiler knows that the object is going to be an instance of the (sealed) Sprite class (or null / undefined, but that's only important at runtime), but it doesn't know much more than that. It will take the property name (a string, remember (and sometimes there's an associated namespace that makes it a two-part string)) that you give to it and check it against a list it maintains of properties that the Sprite class either defines or inherits. If the string isn't in the list, and you have enabled the compiler's strict mode (which is the default), then it will complain.

Often, that sort of error is resolved by casting to a type that more accurately reflects the object's supposed type, like casting to the hypothetical SuperSprite class contains the method that you want. One case that I can think of where that's not really possible is when you use the document class that the Flash authoring IDE generates for you. I don't think that you can (easily? at all?) refer to that class from within your own code because of the weird way that the class in generated. Sure, you can use getDefinitionByName or what not, but that's useless for compile-time type checking. In that case, you can choose to cast your instance to Object because that class is dynamic and also the root of the class hierarchy (or, use array access syntax instead).

Anyway, I personally wouldn't make one of my classes inherit from MovieClip instead of Sprite solely because I wanted to be able to cast to MovieClip so that I could shut the compiler up. The only benefit to doing that that I can think of is that Flash Player will throw a potentially more informative and timely error if your cast fails instead of running along until your false assumption breaks something else. However, it is very rarely the case that I cast anything without being quite certain that it is what I think it is.

[a tadster]

and... you can just do this:

Sprite(this.parent)["myPublicFunction"]();

also, to deal with strict mode.

[Shaedo]

Often, that sort of error is resolved by casting to a type that more accurately reflects the object's supposed type

.... yes .. well ... ahem ... I mean of course *I* would always do that


@a tadster thank you for the idea that's pretty neat.
Whilst I feel I really should be doing as Krilnon said your method seems like an interesting solution. Are there any known dips in performance doing it like this? for example the compiler has to create a string in order to achieve it which is excess system resources ?

[TheCanadian]

and... you can just do this:

Sprite(this.parent)["myPublicFunction"]();

also, to deal with strict mode.

But if you do that, why is your compiler set to strict mode?

[a tadster]

^ yeah, would be better to just turn strict mode off.

i was just saying... and yes, "casting to a type that more accurately reflects the object's supposed type" as Krilnon said is what you should always try to do.

[tbo]

Nice thread, i had asked something like this recently. but i have another question now:

Sprite(parent).prop; // fail, not dynamic class
MySpriteClass(parent).prop; //pass

so by extending Sprite, is this new class MySpriteClass inherently dynamic?

I had done this a week ago, its possible i stated:
public dynamic class MySpriteClass extends Sprite
but i don't remember doing anything to assign it as dynamic

[Krilnon]

Dynamism () is only determined by the concrete class of the object you're using; it's not inherited. Sprite is sealed, MovieClip is dynamic, Object is dynamic.

[kunala]

you can use Sprite as a [base] class for movie clip symbols in your timeline (or the main timeline as the document class) but you cannot navigate to any frame beyond frame 1 and you cannot have ActionScript placed on that timeline. For any of that, you would want to stick to MovieClip. And if not using any timeline features (such as frames past 1 or timeline scripts) theres no point in using MovieClip... unless you want an automatically dynamic sprite without making your own subclass