Recently, I’ve been hacking at low-level AS3 features to try to find a way to load an external image and make a class out of it. Basically, I want to create multiple instances of that image using only the new operator. The image path isn’t known until runtime, so I’d like to make a special Loader subclass that knows the correct image path to load before it gets instantiated. As you can imagine, that’s not the easiest requirement to meet.

Example Application (View Source Enabled)

A short time ago, Ben Stucki created a class to load external images as icons for Flex components. It’s a very clever solution. He uses a Dictionary to associate the image path with the intended parent. I wish I could have used it, but the class I’m trying to create needs to be instantiated somewhere that I can’t access the parent. Like I said, the class itself really needs to know the correct image URL to load. In AS2, it wouldn’t be too difficult to accomplish. You can hack __proto__ in AS2 to do some interesting runtime subclassing to make a unique class for every URL. Unfortunately, Adobe locked things down a bit in AS3 (for performance reasons, mostly), and __proto__ is no longer accessible to developers.

That said, let’s try to remember back even further, to our AS1 days, when true classes didn’t exist. Classes were function objects, and we added member variables and methods through prototype. Thankfully, class-like functions through prototype are still possible in AS3. Consider the following code:

var MyImageClass:Function = function():Loader
{
	//we need a Loader that automatically loads our image
	var loader:Loader = new Loader();

	//the URL will come from the prototype
	loader.load(new URLRequest(this.url));

	//our "constructor" returns the Loader!
	return loader;
};

//the image to load in our dynamically created "class"
MyImageClass.prototype.url = "yahoo_logo.gif";

This creates a constructor-like function that returns an instance of Loader. This loader automatically loads an image URL that we place in the function’s prototype. If you’re using Flex, you could easily modify this function to make it return a SWFLoader instead.

Usage is surprisingly simple. We pretend MyImageClass is a real class, and our friend the new operator takes care of everything.

//add two images to the display list
var image1:Loader = new MyImageClass();
this.addChild(image1);

var image2:Loader = new MyImageClass();
this.addChild(image2);

Two images will automatically load. That’s perfect!

…well, sadly, it’s not perfect. There’s some bad news. I had hoped this would be able to replace Ben’s code in Flex too, but I quickly discovered that while this special pseudo-class (as I now call it) behaves like a real class, Flash Player knows that it isn’t a real Class. For example, the icon style on the Button component in Flex expects a Class object. Our pseudo-class is actually a Function object, and these two types are not compatible. Flash Player will throw a runtime error if I try to set this style to a Function.

Thankfully, I need these pseudo-classes for a component that I built myself. I can ensure that I type my variables correctly (or at least branch depending on the type) so that both Class and Function can be used. As much as I’d like to be able to use these pseudo-classes for icon and skin styles in Flex, that’s just not in the cards.

If you’re interested, I built a utility class called LoaderUtil with a function createAutoLoader() that encapsulates this functionality into a simple function where you pass an image URL, and an optional LoaderContext (for tweaking cross-domain options and other stuff on the Loader), and you receive one of these pseudo-classes back.

As you probably know, abstract classes are not a language feature of ActionScript 3. If you are unfamiliar with the concept of an abstract class, let me explain. Think of an abstract class as a super-powered interface. It defines a series of functions that must be implemented, and it cannot be instantiated directly. It goes a step beyond an interface because it also defines some functions that are already fully implemented.

To use an analogy, all electronic devices generally have the same connector to plug into the wall. However, not all electronics have the same purpose. A coffee maker and a DVD player do very different things. We could make an interface IElectronicDevice to make sure they all have a plugIntoWall() function, but then every device will need to re-implement the common wall plug functionality that doesn’t differ very often. By making a class AbstractElectronicDevice, we can implement the wall plug functionality once, and all subclasses of AbstractElectronicDevice will be able to use it without re-implementing the same code.

The problem, of course, is that the coffee maker and DVD player have different controls for turning power on and off. The coffee maker might have a switch, while the DVD player has a button. We can’t implement the togglePower() function in AbstractElectronicDevice because many electronics will have different controls, so we need some way to force all subclasses of AbstractElectronicDevice to implement this function themselves. Using the methods developed to enforce Singletons in ActionScript 3 as a guide, I’ve found a way to enforce the abstractness of a class at runtime upon instantiation.

There are two main parts to enforcing an abstract class. First, we must stop a developer from instantiating the abstract class directly. To do this, the constructor needs a little special sauce. Since anyone can create an instance of a public class by simply using the new keyword, we need the constructor of our abstract class to require a parameter that only subclasses will be able to pass. Second, we must ensure that a developer implements functions that the abstract class has defined, but not implemented.

Stopping Direct Instantiation of an Abstract Class

The magic bean to stop a developer from instantiating a class directly is one keyword: this. You don’t have access to an instance of a class until after you call a constructor, so only an instance of a subclass will be able to pass a reference to itself to the super class. Let’s look at some code to help make things clearer.

The instance of MyAbstractType expects to receive a reference to itself as the first parameter in the constructor. If it does not, an error will be thrown.

package com.joshtynjala.abstract
{
	import flash.errors.IllegalOperationError;

	public class MyAbstractType
	{
		public function MyAbstractType(self:MyAbstractType)
		{
			if(self != this)
			{
				//only a subclass can pass a valid reference to self
				throw new IllegalOperationError("Abstract class did not receive reference to self. MyAbstractType cannot be instantiated directly.");
			}
		}
	}
}

Only MyConcreteType and other subclasses of MyAbstractType will be able to pass a reference to the instance to their super() constructors. Notice that users of MyConcreteType don’t need to know that it extends an abstract class. The signature of the MyConcreteType’s constructor can be completely different than MyAbstractType.

package com.joshtynjala.abstract
{
	public class MyConcreteType extends MyAbstractType
	{
		public function MyConcreteType()
		{
			//pass "this" to clear the abstract check
			super(this);
		}
	}
}

Forcing Implementation of Functions in Subclasses

Next, like with an interface, we need to force subclasses of our abstract class to implement specific functions. Ideally, we want this enforcement to happen immediately when the object is created (to make bugs visible as early as possible). After we check that the user isn’t trying to instantiate the abstract class directly, we should check to be sure the unimplemented methods are overridden. We can do by checking the results from the flash.utils.describeType() function against a list of unimplemented methods in the abstract class. Again, a little code should give us a clearer picture.

In MyAbstractType, after we check for a reference to the self parameter, we build a list of unimplemented functions in an Array. Next, we use describeType() to get a list of the methods declared in the instance. If a subclass of MyAbstractType overrides a method, the declaredBy attribute in the method XML will specify the name of the subclass rather than MyAbstractType.

package com.joshtynjala.abstract
{
	import flash.errors.IllegalOperationError;
	import flash.utils.describeType;
	import flash.utils.getQualifiedClassName;

	public class MyAbstractType
	{
		public function MyAbstractType(self:MyAbstractType)
		{
			if(self != this)
			{
				//only a subclass can pass a valid reference to self
				throw new IllegalOperationError("Abstract class did not receive reference to self. MyAbstractType cannot be instantiated directly.");
			}

			//these functions MUST be implemented in subclasses
			var unimplemented:Array = [mustBeOverridden];

			//get the fully-qualified name the abstract class
			var abstractTypeName:String = getQualifiedClassName(MyAbstractType);

			//get a list of all the methods declared by the abstract class
			//if a subclass overrides a function, declaredBy will contain the subclass name
			var selfDescription:XML = describeType(this);
			var methods:XMLList = selfDescription.method.(@declaredBy == abstractTypeName && unimplemented.indexOf(this[@name]) >= 0);

			if(methods.length() > 0)
			{
				//we'll only get here if the function is still unimplemented
				var concreteTypeName:String = getQualifiedClassName(this);
				throw new IllegalOperationError("Function " + methods[0].@name + " from abstract class " + abstractTypeName + " has not been implemented by subclass " + concreteTypeName);
			}
		}

		//implemented
		public function alreadyImplemented():void
		{
			trace("Don't forget to list me in the Array of valid functions.");
		}

		//unimplemented
		public function mustBeOverridden(param:String):void {};
	}
}

Now, in MyConcreteType, we can implement the mustBeOverridden() function. If we do not, an error will be thrown. To be certain, try commenting out the implementation of mustBeOverridden() in MyConcreteClass. If you instantiate it, you will receive a runtime error.

package com.joshtynjala.abstract
{
	public class MyConcreteType extends MyAbstractType
	{
		public function MyConcreteType()
		{
			//pass "this" to clear the abstract check
			super(this);
		}

		//implemented
		override public function mustBeOverridden(param:String):void
		{
			trace("param:", param);
		}
	}
}

Conclusions

As you probably noticed, the first part of implementing an abstract class is very simple. Making the abstract class receive a reference to itself enforces subclassing, and it can be done in only a few lines of code. The second part, making an abstract class work like an interface, requires a lot more code, and it may be more prone to errors. You, as a developer, must remember to add all the unimplemented methods to the Array in the constructor. Additionally, if the class gets large, I can imagine that calling describeType() often enough could lead to performance problems. In most cases, as long as you keep your classes clean, it should work well. I highly recommend the subclass enforcement, but I wouldn’t be heartbroken if you feel that checking for unimplemented methods is overkill.

Source code for this tutorial is available for download. It includes all the code above plus an extra implementation (for comparison) of the “electronic device” example I described at the beginning. It’s all under the terms of the MIT license.