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
board.
yours
Martin.
On 17/01/2012 00:52, David Arno wrote:
From: Martin Heidegger [mailto:m...@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.
