On Tue, Mar 03, 2009 at 07:53:24PM +0100, Michael Fötsch wrote: > strk wrote: > >There are many such cases in Gnash. Gnash is pickier about types > >than the proprietary player. This case should be not too hard to fix, > >probably just change the ensureType to require an as_object should work. > > If I understand this correctly, casting to as_object works in this > particular case because "getURL" only ever invokes methods that are > defined right in as_object, such as "callMethod" and > "getURLEncodedVars". It doesn't work in "movieclip_getSWFVersion" > because that invokes "getSWFVersion", which is defined in class > "MovieClip". Correct?
Yes. > However, I don't fully understand when and where the object created in > ActionScript with "new MovieClip()" ceases to be of type MovieClip*. I > assume the "new MovieClip()" in ActionScript leads to a "new > MovieClip()" in C++. Isn't this MovieClip* just being upcasted to > as_object* (while being the same "this" pointer)? Obviously not, because > the "dynamic_cast" back to MovieClip* doesn't work. Where in the C++ > code does the MovieClip lose its MovieClip-ness? (I know this is a > basic question, but any insights are greatly appreciated.) In order for a Derived AS class to be (at AS level) a subclass of MovieClip, you just have to set some special properties (like __proto__). This makes it impossible to know in advance that the actual C type should be MovieClip rather then as_object. With AS2, it's not different, you still know after construction (using EXTENDS opcode). The best we can do is be less typed. You'll find many array functions do work on normal objects, and XML ones too. Implementation wise, supporting this kind of inheritance will come at performance cost. --strk; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
