via wikipedia
Method overloading is a feature found in various programming languages such as Ada, C#, C++ and Java that allows the creation of several functions with the same name which differ from each other in terms of the type of the input and the type of the output of the function.
I’ve wanted overloaded methods in Action Script for some time now. After using it in other languages like java and c# it’s really easy to train your mind to solve one off scenarios with overloaded methods. Much more than an easy way to provide defaults for lots of different scenarios I enjoy crafting them to manipulate program behavior for base or core classes so that the actual implementation of the program becomes much more simple and easier to maintain.
I’ve tried several approaches to getting something similar and elegant in Action Script. Most everything came down to being a hack and turned out to be more work than was necessary to implement. I know overloading is more of an AS thing than an FB thing but thinking about new FB4 features – (my comment is still awaiting approval as of this writing, I mentioned visual studio’s intellisense, oops) the other day made me decide to sit down and attempt overloaded methods one more time. This time I wanted to look at my prominent use cases and see if there was a way to solve this issue.
The two use cases I came across time and time again were 1) eventHandler methods that accept related and similar events: breaking them out to thier own function is do-able but is a lot of work when the difference of how you handle them is 1–off. And 2) methods that take a UIComponent of some sort that either gets or sets data. For example, if you were to loop over an array of form input controls reading / writing data to them you’d find the difference in how you set or get data on them is very similar but just a little different. A TextInput just reads and writes to the “text” property. A ComboBox might read and write to a selectedItem[”property”] value. Or you might want to pull the htmlText value off the RTE.
With those use cases in mind, I thought about how I could handle the two problems simply and elegantly, not necessarily by overloaded methods but just something that could slim my code down, drop a lot of casting, and at the very least make my code more maintainable and more precise in it’s intent.
The first obvious thing I saw was that I didn’t need to worry about the number of arguments, although the technique I’m gonna demonstrate can be used with multiple parameters or event the …rest params. In my case I’m handling an event or a view in both cases. The second thing I saw was that I’d almost solved this problem. In most of these methods I was just accepting either an Event or UIComponent or something similar. The next thing I noticed was that I was either casting from within switches or if statements and I was executing my computing goal from within my function or calling an outside function to accomplish something. With that in mind I decided calling an outside function was the best method. Indeed, once you identify what you want to do, with overloaded methods you can easily add more methods with different signatures that all call your most basic function. The names on all the methods are all the same. Your code becomes very clear in it’s intent. It’s not saveEmployee(), saveUser(), it just becomes save(user), save(employee). It’s important to note that I understand the former examples are very intent. However, the latter examples, when working in teams or groups, it’s much easier to learn and remember save(variable) and when you want to save an object and you don’t know if it’s an Employee or User you don’t have to worry about it because in most languages the compiler creates your switch or if statements for you.
( you should be able to see the next step with overloaded methods, which is to dynamically interpret objects you didn’t know about save(order), save(product) for example. Ruby on Rails made this kind of processing retro the past few years, but I’ve been doing something similar with coldfusion argumentCollection for years now. Check out Proxy if you’re interested in that. )
So to get to the demo, I created two functions with the same name eventHandler(), eventHandler(). My first method is my bucket. It’s where I want to throw everything into. My second method is my target method, the method that does the cool kick ass thing I want it to. It takes very specific arguments. Obviously it didn’t compile. So I created a namespace in the default package ( so I don’t have to import it ) called overload. I made my first method public and put my second method in the overload namespace. I reworked how I called the overload method and it compiled. To interpret my arguments I use a switch statement or if statements depending, like i was before. My code then becomes very intent. It at least accomplishes my goals with overloaded methods.
A couple thoughts on this technique. First, I looked for but didn’t find that overload was a future reserved word in ActionScript. It feels like something that might be. Secondly, ActionScript should define overloaded methods, the compiler should implement them and and FB should support them.
Here’s the live demo. Right click for source.
Recent Comments