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!

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.

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” ?!?!?!?!??!

//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.

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.

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.