AS3 override addChild(), test for type

Question

this works for me, but does it look correct in terms of as3 best practices. is it correct to return null if it fails?

        override public function addChild(child:DisplayObject):DisplayObject {
        if(child is Screen) {
            super.addChild(child);
            return child;
        }

        return null;
    }

Answer 1

I don't see why not. I've never actually used a return value of addChild in practice. You'd need some way of knowing if the child had been added so you could then use:

if (!addChild(child))
{
   //couldn't be added
}

instead of

if (child is Screen)
{
    addChild(child);
}
else
{
    // couldn't be added
}

Or you could instead throw an error in your override and catch that if it's not an instance of Screen.

I don't think it's a best practice issue at all if it works for you.

Answer 2

I see a couple of options and none feels completely "right".

The best solution, as I see it, is not possible in Actionscript (I think this is allowed in other languages). That is, declare that you will accept only instances of Screen:

override public function addChild(child:Screen):Screen {
    return super.addChild(child);
}

Since that's not possible, the other options I can think of would be:

1) Throwing an Error.

I'm generally not very fond of throwing Errors, but a pro here is that it matches the behaviour of the extended class. If you pass a non valid display object to addChild, it will throw. On the other hand, this is valid given that the method signature tells you that you have to pass a DisplayObject. In this case, your method is "lying", in a way, because it says it accepts DisplayObjects but it really only accepts instances of Screen. So you are relying in documentation (hopefully) rather on the type system to tell the user code how it's supposed to use your function.

2) Adding an addScreen method that calls addChild.

public function addScreen(child:Screen):Screen {
    return super.addChild(child) as Screen;
}

This is somewhat more typesafe, but you lose some of the advatanges of polymorphism (and perhaps it's not possible / feasible in your code). Maybe if we had method overloading... but we don't so, again, I guess it's a tradeoff.

3) Runtime type checking and returning null on failure.

This is what your code does. It could be just fine. What I don't like about it is what I mentioned above: that your method is kind of "lying". I don't expect a method that takes a DisplayObject to fail because I passed a DisplayObject. But well, sometimes, this is not a big deal.

I'm afraid I can't really give a definite answer on this. If possible, I think I'd probably go with option 2), but all these options seem equally valid. At some point you have to settle for the one that makes more sense for you and your project, I guess.

Answer 3

There is no good way to do, what you want to. If you want the desired behaviour, you are to use composition instead of inheritance. What you're trying to do is violating the Liskov substitution principle.