Comments on: ActionScript 3: Handling Inheritance

By: Youdgin

Youdgin — Tue, 07 Dec 2010 13:51:06 +0000

I have a problem if someone can help. I have a double linked list implemented and for a class ListNode wich has properties next:ListNode and prev:ListNode (wich are instances of their own class) and obj:*. My problem is how do I inherit the class ListNode let’s say with the class ListGeniNode(that is what actualy i need) in that way so i can access methods of the child class through the properties of the parent class. Example:
public class ListNode{
public var next:ListNode;
public var prev:ListNode;
public var obj:*
//constructor goes here
}
public class ListGeniNode extends ListNode{
//constructor goes here
public function get geniTreeNode():GeniTreeNode{
return super.data as GeniTreeNode;
}
}
class main{
function main():void{
var node:ListGeniNode = new ListGeniNode();
node.next.obj = new GeniTreeNode();
trace(node.(next as ListGeniNode).geniTreeNode);//returns null but not the object GeniTreeNode
}
}

And i sort of know that you cant cast the parent instance to child but is there a way around this and any suggestions are welcomed.
The reason is the proper reusing of the Class ListNode(because the getter is available only for GeniTreeNode type objects) and to know what to do if I find similar cases like this. Thank You!

By: Eric Hawthorne

Eric Hawthorne — Mon, 18 Aug 2008 23:30:13 +0000

Regarding the original problem.
Look up the terms “covariant inheritance”
and “contravariant inheritance”

O-O programming languages take different points of view on this
issue. Both POVs have merits.

The contravariant case says: Look: I might want to have a setter method on the FruitTree that says e.g. setFruit(f:Fruit).
Now since the proper interpretation of inheritance is “isa” then an AppleTree isa FruitTree, and whatever I can call on a FruitTree, I must be able to also call on an AppleTree. So I call
aFruit:Pear = Pear()
myAppleTree.setFruit(aFruit)
and, according to the contravariant interpretation of “isa”
contracts, that argument needs to be accepted, because it meets
the type criteria on the setFruit method.

Covariant inheritance (of method argument type constraints)
would say no, what we are doing is defining a specialization
hierarchy of whole-part objects and we need structural (part)
specialization when we specialize the type of the “whole”.
So we should allow the setFruit(f:Fruit) method to throw
an “incompatible part type” exception if we send a Pear in
to be part of an AppleTree.

Java takes the contravariant view for method argument type
constraints, but allows covariantly specialized return types
on method return values, which is less controversial, since
a covariant (more specialized type returned by method call
on subclass) still meets the typ constraint specified on the
general class version of the method declaration.

By: Josh Tynjala

Josh Tynjala — Tue, 18 Mar 2008 18:56:20 +0000

tom, I’m pretty certain that is the correct behavior. As a private constant, MYCONST will always be “A” within class A and that’s where the toString() method is located. MYCONST as specified in class B is a completely different constant that cannot be accessed from class A.

By: tom

tom — Tue, 18 Mar 2008 18:38:55 +0000

ok, here is what I consider a serious bug in the inheritance of as3

class A {
private const MYCONST:String = “A”;
public function A(){}

public function toString(){ return this.MYCONST; }
}

class B extends A {
private const MYCONST:String = “B”;
public function B(){ super() }
}

trace( new A() ); // prints “A”;
trace( new B() ); // prints “A” ?!?!?!?!??!

By: ryan

ryan — Fri, 08 Sep 2006 18:54:04 +0000

I agree with the interface assessment. I may be missing something regarding the intended usage, but the interface structure is there exactly for the case where you want to pass multiple types around in one place. In conjunction with a superclass, you can then have a class that you can pass around as any of the interfaces that it implements, while still allowing it to inherit common functionalities (or override) from the superclass. Taking advantage of this (or being forced to do this ) also helps force you into thinking a in a bit more organized fashion, which is nice sometimes…

By: Josh Tynjala

Josh Tynjala — Thu, 11 May 2006 18:11:51 +0000

Here’s an interesting solution that is similar to David’s.

//In FruitTree class
protected function initializeFruit():void
{
this.myFruit = new Fruit();
}

//In AppleTree class
override protected function initializeFruit():void
{
//AppleTree now includes a myApple variable
this.myApple = new Apple();
this.myFruit = this.myApple;
}

It still clutters the class with an additional property, which I’m not a fan of. I’d use this one over David’s to bypass the overhead of calling a function and casting myFruit as an Apple.

By: george

george — Thu, 11 May 2006 15:21:56 +0000

Probably not the best idea, but simple. You can just use a wildcard in myFruit declaration. myFruit:*

By: Josh Tynjala

Josh Tynjala — Thu, 11 May 2006 03:39:05 +0000

Actually, that won’t work Mike. It will cause an “Incompatible override” error. That was the first thing I tried.

By: Mike J

Mike J — Thu, 11 May 2006 03:29:01 +0000

I would actually take Davids example and make it a bit more generic. Haven’t done AS3 yet, but to illustrate:

Class FruitTree {
private _myFruit:Fruit;
public function get myFruit():Fruit { … }
}

Class AppleTree {
public function get myFruit():Apple {
return _myFruit as Apple;
}
}

That way, you can still access it using this.myFruit but it should be cast correctly without adding boatloads of extra code.

By: Josh Tynjala

Josh Tynjala — Thu, 11 May 2006 03:05:55 +0000

That’s an excellent example, Todd. It shows why a developer would want to use interfaces (something many have trouble understanding right away), and it helps illustrate how one can abstract an action (such as removing a stem) into a more generalized form (like preparing the fruit) so that it can be used across many different kinds of related objects. You should post it on your blog. I’m sure a lot of people could benefit from it.

I’m currently migrating a good deal of code (probably a hundred classes or more) from AS2 to AS3. Building the original code, I ran into many situations just like that, and I used similar solutions. Some objects have more obvious connections than others, obviously. I’ll have to spend some time looking for nice generalizations like that. Now’s probably the best time to do it, too, since we’re working on such a big transition.