This post provides some example-code for the concept presented in my previous post, please note that this post serves only to add some concrete material to the abstract idea presented in the previous post and that the focus should be on the latter rather than the former. This post is not at all about best practices or good/bad code-architecture.

I first started thinking about using namespaces for overriding methods when at the end of july I was talking to Tommy about a problem he was having. He had overridden addChild() in some distant DisplayObject subclass but in some situations still needed to use the original implementation of the method. Because for this he used super.addChild() he was forced to put a lot of different logic in that one single subclass.

The implementation of the double-overriding popped up when I suggested to store the original addChild() functionality in a duplicate function defined with a custom namespace and the same name, and then put the rest of the functionality in a subclass of the class that would override addChild():

// DisplayObjectOverridden.as:
package
{
   import flash.display.DisplayObject;
   import flash.display.Sprite;
 
   public class DisplayObjectOverridden extends Sprite
   {
      public function DisplayObjectOverridden ()
      {
         super();
      }
 
      override public function addChild(child:DisplayObject):DisplayObject
      {
         // custom functionality
      }
 
      original function addChild (child:DisplayObject):DisplayObject
      {
         return super.addChild(child);
      }
   }
}

// OtherFunctionality.as:
package
{
   import flash.display.Sprite;
 
   public class OtherFunctionality extends DisplayObjectOverridden
   {
      public function OtherFunctionality ()
      {
         var normalChild:Sprite = new Sprite();
         addChild(normalChild);
 
         var specialChild:Sprite = new Sprite();
         original::addChild(specialChild);
      }
   }
}

// original.as:
package
{
   public namespace original;
}

When namespaces were first introduced in Actionscript 3 I thought it was all pretty cool, but still I sort of had a difficult time thinking of actual use-cases.

What I initially would have liked to use custom namespaces for was to restrict access to certain properties/methods, to only be accessible for certain classes, in the way that private and protected enable you to -- unfortunately there is no simple way of defining who can import your namespace, consequently rendering namespaces somewhat useless for this particular use-case.

Then some time ago it struck me that rather than defining new members with a custom namespace, that you could of course also enhance an existing method instead (I admit this might seem like a no-brainer, but it took me a while to bump into).

Let's say you have a subclass that for regular (outside) usage needs to override a method in the superclass, but itself still needs to use the original (super-) method. You would probably just override the method in the subclass and use super.method() wherever you needed to use the original functionality.
Now let's say that you need to make a subclass of your subclass, which would also require access to the original functionality in said method. All of a sudden super.method() will not work for you anymore.

Here's where namespaces start coming in handy, while still simply overriding the method in the first subclass, you also implement a function with the same name but with your own namespace (for example "original"). Then whenever you need to call the original implementation you can call original::method(), regardless of how deep down in the inheritance-chain you are.

This is only one use-case, you could for instance also use this concept to work around the nasty ambiguous-reference bug you get (or used to get) when declaring a getter and a setter with different (native) namespaces.

To keep the focus on the above described concept I put the example-code in a seperate post, feel free to read on though.