+1  A: 

I don't quite understand the purpose of this class structure you describe (the class names confuse me), but in general a few things come to mind that might help you:

Almost always the best solution is to try and rethink your class model by evaluating whether you should for example break up the responsibilities of classes in an alternate way so that you could utilize inheritance and polymorphism in a better way.

"The problem is that the object I use, is of the type AnimatedCharacter, so I can't just put it in a variable of type CharacterPhysics."

If you want to put an AnimatedCharacter into a variable of type CharacterPhysics, the former should extend the latter, or you should have a common interface (or superclass) for both and then type the variable as such. If this is not possible, my opinion is that you should probably try to rethink and refactor your whole class structure, assuming that you have a solid "object-oriented" reason for wanting to do this in the first place ;).

If the above is not possible, there are some other tricks you can evaluate in your context:

  • The use of mixins can work as a "poor man's multiple inheritance". Derek Wischusen has some examples on how to implement them in AS3 at flexonrails.net.
  • "Kind of" implementing the decorator pattern with flash.utils.Proxy. The problem with this approach is that you defer a lot of error checking from compile time to runtime, but the good thing is that you don't have to manually write the "proxying" implementations of all of the methods of the "decorated" object, but write just one (callProperty()) instead.
hasseg
A: 

You can interpret a sublass as an instance of a superclass but not vice sersa. Did you state this backwards?

If so, you could use:

vas cp:CharacterPhysics;

...

var ac:AnimatedCharacter = cp As AnimatedCharacter

le dorfier
A: 

Off the top of my head, it seems like those 2 should be interfaces which your main class implements

Iain