constellex

Overloading methods, or functions, is an extremely powerful technique available to programmers in many object-oriented languages (Including Java, C++, etc.). Adobe, however, decided to leave this functionality out, which was a cause for many unexpected design changes to my recent ActionScript project. As a brief review, or introduction for programmers new to object-oriented programming, overloading methods allows for various different strategies. For example, we could have a method with the following prototype:

public boolean parse(String myStr);

As well as another method in the same class with the following prototype:

public boolean parse(int myInt);

There are a couple benefits we gain by being able to use this technique. For one, we could use this technique to simply allow a programmer using the class to be able to pass either a String or int to the parse method. A sample implementation in Java might be:

public boolean parse(String myStr) {

	// perform parsing algorithm on myStr

}

public boolean parse(int myInt) {

	return parse(String.valueOf(myInt));

}

Sure, the programmer that needs to use this class could simply cast/convert the integer to a String first and then call parse, but this makes things a little bit simpler for them. Overloading, however, gives us even more flexiblity. What if the parsing algorithm needed to change based on the object passed in? You couldn’t accomplish this with ActionScript 3.0 since it does not support method or constructor overloading. The rules are simple. You cannot have a method named the same as another method, regardless of differing return types or parameter lists.To the advanced programmer, you can see how limiting this is. How do we solve it? Well, to be honest, some of the cases I’ve pointed out can’t be solved in ActionScript 3.0. If you want to provide different algorithms based on the passed in object(s) via the same method name, you can’t, you need to make different methods with different names.If it is absolutely necessary that you support multiple algorithms based on the parameter passed in, you need to look into implementing the Strategy pattern. If you don’t need all of the overhead of an interface with concrete algorithm classes from the strategy pattern, you can hack this functionality in like so:

public function parse(o:Object):Boolean {

	var retVal:Boolean = false;

	if ( o is String ) {

		retVal = parseStr(o as String);

	} else if ( o is int ) {

		retVal = parseInt(o as int);

	}

	return retVal;

}

public function parseStr(myStr:String):Boolean {

	// Algorithm for strings here

}

public function parseInt(myInt:int):Boolean {

	// Algorithm for integers here

}

Yes, that’s hideous. Each time you want to be able to parse another type of object you need to add another function and modify the original parse one. Oh, and there’s no compile time checking to make sure that users of your class aren’t passing in an instance of Object that isn’t supported. So you’d need to add functionality to throw an exception. Hopefully Adobe adds method overloading in 4.0. Next up for part 3, unnecessary syntax.

ActionScript 3.0 is the new version of the Adobe Flash scripting language. ActionScript 3.0 is supposed to be a better implementation of Object-Oriented paradigms. Through my learning of ActionScript on my latest project (A XML Object-Relational Mapper between web services), I have come across several gotchas and frankly annoying things about ActionScript.

I will be doing a several part series on the various problems I’ve encountered using ActionScript and how to get around them or how Adobe should fix them. Either way, knowledge about these things is important to the typical OO programmer looking to learn ActionScript.

Private constructors. Although not the most commonly used feature of most object-oriented languages, they are essential for one of the most famous, or infamous depending on the programmer, design patterns. The Singleton. For those not in the know, the Singleton pattern is used for enforcing only one instance of a specified class. There are many uses for this, but I’ll leave that discussion to a place with a little more room.

ActionScript 3.0 is missing private constructors. This is intriguing for two reasons. One, private constructors were allowed in ActionScript 2.0. Two, private constructors were removed with what seems to be no reason. I have been unable to find any documentation as to why they were removed. This makes implementing the Singleton pattern rather strange. So how do we do it?

package com.constellex.actionscript {

	import flash.utils.getQualifiedClassName;

	public class Singleton {

		private static var instance:Singleton = null;

		public static function getInstance() : Singleton {
			if (Singleton.instance == null) {
				Singleton.instance = new Singleton();
			}
			return Singleton.instance;
		}

		public function Singleton() {
			if ( getQualifiedClassName(super)
				!= "com.constellex.actionscript::Singleton" )
				throw new ArgumentError();
			} else {
				// Your constructor code here
			}
		}

	}

}

The only difference this ActionScript 3.0 implementation does differently is that instead of checking at compile time whether you are correctly using the Singleton object, it will throw an ArgumentError exception if you attempt to instantiate the Singleton object outside of the Singleton class. The getQualifiedClassName(super) gets the name of the class calling the method, which allows the Singleton to check and make sure only the Singleton class can call the constructor.

Next up in part 2, overloading methods.