I used to think that method overloading had no place in OOP, but there are
certainly use cases where it could be used. I agree a new method with a new
name is preferable, but sometimes that's not the most ideal.
Here's an example I thought of that method overloading would solve...
If you've used as3-signals you're familiar with this line of code:
someObject.mySignal.dispatch("A string arg", 5); // Where someObject = new
Signal(String, Number);
I love signals, and I've used them for a while in my projects. However,
when writing APIs with signals, like I did with MongoAS3 (), the signal
objects become a little annoying for new users because the IDE does not
code hint the dispatch class. The user has to either look through ASDocs
(which I haven't made for my lib) or they have to look through the source,
and find the object instantiation for "mySignal" so they know what type of
payload arguments the Signal is expecting.
If we had method overloading I could do this:
override public function dispatch(username:String, anID:Number):void
{
...
}
Then the user would not have to figure out that there are decorator methods
around dispatch(), they can always use the same method for all Signal
objects, and the IDE would tell them exactly what type of arguments the
method expects.
That's just one example I've thought of... and I get that I can make a
method called dispatchMySignalWithAStringAndANumber()... but yea... I'd
much prefer to overload the method than have a bunch of methods like that,
maybe I'm crazy and have spent too much time in Android/Java.
-omar
