So, what’s the deal with sealed subclasses of dynamic classes? First of all, if you have a class like this:
package {
import flash.display.*;
public class SealedClip extends MovieClip {
public function method():void {
this.q = 5; // compiler error, of course
trace(this === super); // true
super.q = 5; // runtime error, ReferenceError: Error #1056: Cannot create property q on flash.display.MovieClip.
this['q'] = 5; // ReferenceError: Error #1056: Cannot create property q on SealedClip.
}
}
}
// elsewhere
var clip:MovieClip = new SealedClip();
clip.property = '10'; // ReferenceError: Error #1056: Cannot create property property on SealedClip.
clip.method();
…you run into issues since the compiler can’t catch the errors, which is expected, but still fairly silly. The weird thing is that this === super, but the error claims that super is a MovieClip. If it really was a regular MovieClip, though, then an error wouldn’t have been generated. I’m guessing that the SealedClip instance doesn’t actually contain a full MovieClip instance, because a regular MovieClip would have a hashtable of properties. Instead, only the MovieClip’s trait object is being passed on to the SealedClip, so the SealedClip instance won’t have a property hashtable either. That still doesn’t really explain why super thinks that it is this. The AS3 documentation doesn’t really clarify anything, either.
The super statement provides such a mechanism, in that it contains a reference to the immediate superclass.
Since I’ve tried to establish that an actual reference to the superclass doesn’t exist (or at least not a reference similar to one that you would get when instantiating the superclass by itself), the documentation’s statement can’t be quite correct. So what’s really going on with super here?
In a somewhat related matter, I find it somewhat amusing that sealed subclasses can break their parents:
package {
public dynamic class DynamicBase {
public function DynamicBase(){
dynamicMethod();
}
public function dynamicMethod():void {
this['dynProp'] = 'dynValue';
}
}
}
// ...
package {
public class SealedSubclass extends DynamicBase {
}
}
// later
var klass:DynamicBase = new SealedSubclass();
/*
ReferenceError: Error #1056: Cannot create property dynProp on SealedSubclass.
at DynamicBase/dynamicMethod()
at DynamicBase()
at SealedSubclass()
*/
It makes sense that that error occurs, since the methods are being called in the context of the new, sealed object that is being created.
My question is, was this done purely for performance and to maneuver around difficulties created with the dynamic Object class? It seems that in another AS3 implementation, one could have had a hashtable made for an object only if one or more of its defining classes was dynamic. That way, the penalty of adding the hashtable would always exist as long as there was one dynamic class in the inheritance chain, but then one wouldn’t run into trouble with breaking existing classes simply by sealing a subclass. Of course, such an implementation would cause problems due to the Object class being dynamic, since all instances would then need a hashtable and all of the performance gains gained from allowing sealed classes would go away. One then wonders whether or not it was a good idea to make the Object class dynamic. It probably would have been too big of a compatibility issue to seal the Object class for AS3, so I can see why it is still dynamic and why sealed classes eliminate the hashtables that would otherwise exist… at least in the actual implementation of AS3. Perhaps making the object class dynamic was just the result of a lack of ability to see where ActionScript would eventually be headed, which is more than understandable. To me, it seems that it would make more sense to have some sort of HashTable or similar class be the base class for dynamic classes, and then leave Object as the base for all other classes (since it seems that most classes don’t need to be dynamic), if one was going to allow sealed classes at all. I’m pretty sure that that’s what’s done in languages like Java.
Does the above analysis seem correct? (-: This is the sort of stuff that I am actually interested in, so I would appreciate comments.
Of course I would still appreciate more thoughts from you or others, since I don’t think we’ve quite reached the bottom of the mystery, so to speak.