And my main reason for it is cross-version backward compatibility.
That is a valid implementation issue to me. In Java this is solved in
the runtime. Personally
it is enough for me to just throw a notification during compilation that
can be turned off:
"Warning: Overloading is a new feature that might break older code! You
can turn this message off by setting the
compiler.warn-overloading property to false"
I'm all for using descriptive names instead of overloading where possible,
until you get into situations where the API seems overwhelming because there
are 25 methods that start with "set", and forcing folks to use a descriptive
name for an additional optional parameter you want to add in the next
version doesn't scale. Soon, the API docs just overwhelm you.
Making descriptive names is okay but having over-descriptive names are
not necessary.
Names like "saveString" are for me in this particular category.
Method overloading seems to contribute to API bloat in Java since every
variant is in the doc,
So: The problem is that every variant is documented instead of some
variants might be without documentation?
Having every case documented sounds kinda good to me. It would be
possible to reduce the duplicates in API docs with improved templates.
The too-much-information problem is usually solved with a different
design, but that's a problem with documentation
in general and not overloading in particular... imho.
The biggest difference between Java and AS3 is that in Java there were
no default values or
variable argument length for almost a decade.
We can write methods like
function myMethod(a: String = null);
in Java you were forced to write
myMethod();
myMethod(String a);
of course resulting in a lot of overloading-use where its avoidable in
AS3 already.
yours
Martin.
