No - it _doesn't_ change the type of the variable from the compiler's PoV, that's my point. :-)
I've probably been explaining really badly. The statement: var my_var:A; defines a thing which can point to objects of type A. This thing can only _ever_ hold references to objects of type A and objects derived from A; never anything else. So, assuming class C extends class B which extends class A: var b1:B = new A(); // Compiler chokes, as it can't guarantee that all the methods B defines are available in A. Compilation would stop here. var b2:B = new B(); // no problem var b3:B = new C(); // again, no problem, because C inherits from B and the compiler is happy that C can do everything B can. b2.doAMethodDefinedInA(); // Fine - compiler knows that B extends A b2.doAMethodDefinedInB(); // Again, fine. b3.doAMethodDefinedInA(); // Still fine b3.doAMethodDefinedInB(); // Yup. b3.doAMethodDefinedInC(); // Nope. The compiler thinks that b3 is of object type B - it knows nothing of C, because 'b3' was defined as being of type B in it's declaration. Note that the last line would compile fine if class B were defined as 'dynamic' - because it's dynamic, the compiler throws out all type-checking on B. There go the safety-nets... which is what was happening in your MovieClip example. Now, if the _programmer_ was happy that b3 was _actually_ a C, he could always type: var c:C=C(b3); // Downcasting is perfectly legal... c.doAMethodDefinedInC(); // And now the compiler is happy I hope that's clearer. :-D But now I'm probably waaay off the original topic, whatever it was... sorry, it's been a helluva weekend. ;-) Ian On 10/31/05, JesterXL <[EMAIL PROTECTED]> wrote: > > To clarify, it changes to the type as far as the compiler is concerned, > but > at runtime, yes, it's just a MovieClip. > > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
