Did you know ActionScript 3.0 supports multiple inheritance? Here's how...

Multiple inheritance is actually possible with AS3, despite popular belief that it's not supported. It's not really multiple inheritance in the true sense of the word going by the strict definition... but there's a way to get the job done in AS3 that behaves almost like the real thing.

What I'm about to show you is not something I would advocate as best practice. Nor is it something that should be (ab)used simply because it's available. I'm not going to get into the debate about Composition versus Inheritance and how Multiple Inheritance fits into the picture. If you're here, it's probably because you want to know how to use this technique. I assume you also know then the various repercussions (and if not, at least have the ability to Google them). As they say, "with great power comes great responsibility."

Various disclaimers aside, here we go...

When you simulate the use multiple inheritance, there are three things you need to do:

1. You need to create an interface that defines the methods you want to use.
2. You need to create a default implementation for that interface.
3. You need to merge the default implementation for the interface into the class you want the methods available in, and mark the class as implementing the interface.

It's the last step, the merging of the default implementation, that simulates multiple inheritance. "But Darron," you say, "an interface can't have a default implementation!" To which I say, "You're absolutely correct!"... now what? ...drum roll...

Did you forget that ActionScript 3.0 is a dynamic language and supports a long-since-forgotten-about-since-ActionScript-1-days but still-supported-because-its-in-the-spec #include pragma?

This is where it gets ugly, but stay with me. We'll create an interface, and then write the implementation for that interface in a free-standing .as file that contains just loose ActionScript code. Then, like magic, we'll include that file in our class and have the compiler automatically insert the code. The result? A class that implements an interface, with a default implementation that's separate from the class, and re-usable through many classes.

Here's a concrete example to further drive home the idea:

// In CartoonCharacter.as

interface CartoonCharacter
{
function setSpeechBubbleText( text:String ):void;
}
// In ChartoonCharacter_impl.as
public function setSpeechBubbleText( text:String )
{
    trace( "setting speech bubble text to: " + text );
}
// In CartoonDog.as
public class CartoonDog extends Sprite implements CartoonCharacter
{
    // Check out that bling bling.. fo shizzle!
    #include "CartoonCharacter_impl.as";

    public function CartoonDog()
    {
      // Constructor
    }
}
// In CartoonCat.as
public class CartoonCat extends Sprite implements CartoonCharacter
{
    // Here it is again... oh no he didn't!
    #include "CartoonCharacter_impl.as";

    public function CartoonCat()
    {
      // Constructor
    }
}

From the above series of code blocks, hopefully you can see what happened. In our "impl" file we just have a method name and a method body. The method body is the default implementation for the CartoonCharacter interface. In our CartoonDog and CartoonCat classes, we include that default implementation and implement the interface.

If you ask the dog if he's a CartoonCharacter, he'll surely respond that he is. Likewise with the cat...

if ( dog is CartoonCharacter )
{
    trace( "bow to-tha wow, yo!" );
}

... but by having the implementation in a separate ActionScript file, it allows us to pretend that both dog and cat inherit from CartoonCharacter. When we change the "impl" file, we change the behavior for all of the classes that #include the file. This is important because in this use case, we have to extend a display object class so we can be added on screen.

Now, I know the first question will be "Why not just make CartoonCharacter a class that extends Sprite and have Dog and Cat extend that?" to which I say, "you completely missed the point of this article."

All that aside, there are a few gotchas to using this technique. In no particular order:

• You can't override the default implementation. Since we're #include-ing, using the override keyword and trying to roll your own won't cut it.
• If you include many "impl" files and they have naming collisions (methods with the same names), you'll get a compiler error and the class won't compile. This is a good thing in my book.
• If your default implementation uses other classes, you have to be careful of the "import" statements since the class that's #include-ing the file needs to import those classes.
• No real help fom FlexBuilder, but that's to be expected.
• .. add your own "you suck, this technique is stupid and doesn't work because of XXX" reason here.

In the import case, I've been keeping a separate "MyInterface_imports.as" file, and then #include-ing it at the top of the class with the other imports. There can still be some issues here with multiple inclusion of the same class, but that's not a compiler error (at least, not yet anyway).

Anyway, like I said, use with caution. There are definitely cases where this approach works well, and there are other cases where it's better to change your architecture and avoid it. I leave it as a thought exercise to you to know when to use it and when not to. Don't go crazy, kids, you might want to keep the training wheels on for this one...