Problems with ActionScript, Part 2
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.