|
The important points to note from the demonstration are:
In the new handler, the "me" reference is to the script being created. In the case of an ancestor, this is a reference to the ancestor itself, never the descendant.
For this reason, it may be a bad idea for scripts to store references to their own "me" somewhere, in the new handler. This is because if the script is an ancestor, then the stored reference will not be to the real object, but to the ancestor instance, which as we can also see, is an isolated instance in it's own right.
For example, if an object were to add itself to the actorList in it's new handler, then if it were an ancestor, it would not be adding the true object reference (the descendant). Instead, it would merely be adding a reference to itself: the ancestor instance. In some cases that may work, but where properties or handler are overridden in the descendant, it will almost certainly fail.
Ancestors are an isolated instance (entirely independent of the descended object) that is accessible by explicitly referencing descendant.ancestor. This instance does not have access to properties of the descendant. From this perspective, overridden properties retain the values from that instance, not the overriden values of the descendant (normally considered the true values for that object).
CallAncestor can invoke an overridden script in an ancestor, while the object reference remains that of the descendant object. In this form, me.property is the "true" property from the descendant object, not any overridden property of the same name that may also exist in the ancestor.
Only the explicit "me" reference will refer to the descendant object! The implicit "no reference" form will still refer to the ancestor instance. In this form, all overridden properties relate to the property in the the ancestor script, not the "true", overridden property from the descendant.
|
