flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger ...@leichtgewicht.at>
Subject Re: AS3 Enhancements: method overloading. Why do people want this?
Date Mon, 16 Jan 2012 16:28:51 GMT
I do remember that on more than one instance I have had that problem. 
During a project - on a schedule.
As it were always one of many problems I solved it and now of course do 
not remember the particular details.

However, in my experience it was usually a problem with common method 
names. Most prominent example is:
toString(); If you go to the implementation of toString() for integer 
than you will find that it uses a argument (radix).
However String.toString doesn't and Object.toString() as well. toString 
is not officially part of an "Object" signature.
It gets resolved by using the (still existing) prototype chain. Many IDE 
tools have problems with that as its not typed.
Other prominent examples of such conflicting method names are: render, 
save, add (addItem, addChild, ...), move, create, etc.
But I have seen more complex examples too.

However: Even if I can't produce an example that satisfies your need: 
You asked for a reason as to why overloading is important to people.
This is a reason, and its a valid one. There is no proper workaround we 
just live with it somehow during or daily coding.

To conclude my answer to your question: These are the positive impacts 
of overloading to a language I know of:

*) It becomes possible to implement two interfaces with different method 
signatures for the same method name.
*) It becomes possible to add a parameter to a method in a extended 
class -> toString() + toString(radix);
*) Instead of a run-time-type-check-switch: Overloading with 
compile-time-type-checks are faster.
*) Instead of a run-time-type-check-switch: Overloading might never 
throw an exception due to wrong type.
*) Documentation of different logic for differently typed arguments is 
shorter (no explanation as to which types are allowed).
*) IDE's can support different argument types (shows a list of arguments 
allowed) and the documentation for this particular method.

There are also negative impacts I am aware of:

*) Coding out all variants of all combinations of arguments can be 
horrible. (but: in as3 we have ...args)
*) Two methods have a bigger impact on the swf size than one method with 
an if switch.
*) People might be confused as to which method they should use 
(although: I never had that problem)

Right now there are various, hack-like ways to workaround the 
"having-no-overloading" problem. As overloading is
optional (no-one needs to use it) the negative impacts are all 
voluntary. So: Yes we can live without overloading (we did so for quite 
a while)
but I think it would be good for the overall code quality to have it on 


On 17/01/2012 00:52, David Arno wrote:
>> From: Martin Heidegger [mailto:mh@leichtgewicht.at]
>> Sent: 16 January 2012 15:22
>> To fix it by renaming one would need a complex naming convention in
> interfaces like:
>>   function<namespace>_<functionality>()
>> Because if we create a interface we don't know in advance what other
> interface
>> from other frameworks it might be used with it: that means you better
> write something
>> like this:
>> interface IContext {
>>    function get robotlegs_core_destroyed(): Boolean; }
>> because some other interface might have another getter for "destroyed"
>> of which the robotlegs team doesn't know in advance.
> Unless you are creating an overly-large class, it is incredibly unlikely
> that you'll need one class to implement two interfaces that both contain the
> method "destroy". Remember, if you aim for classes to be single purpose,
> this problem should not occur. Or do you know of a real-world situation
> where it can occur?
>> (btw.: Complaining about non-descriptive function name in a
>> example without implementation is tedious)
> Sorry, I wasn't complaining about "test", I was just using it as an example.
> The better the name the less likely that there would be a conflict. Guess it
> didn't come across that way :)
> David.

View raw message