To overload or not to overload (was Eiffel and Java + Ada dispatching)

[donh@syd.csa.com.au (Don Harrison)]

Robb Nebbe writes:

:you need to keep in mind that a language is a tool. People become very frusterated
:with tools that interfere with doing work rather than help, unless they can
:rationalize this in terms of saftey or something. Overloading is the language
:getting out of your way so you can concentrate on what is really important.

This may be true in some cases (eg. for Ada) but there is also a downside. 
(See below).

:Think of it as separation of concerns. When you are writing software it is better
:to concentrate on finding meaningful names rather than "Did I already use that
:somewhere?" I have better things to do than manually resolving overloading.

IMO, operations that do the same thing should have the same name and there
should be only one operation per class that does a particular thing. In 
particular, overriding operations should retain the same name (unless a more
specific name is in order due to specialisation). Further, if two operations 
do similar but different things, they should still be given distinct names. 
My justification for this is that it is easier to understand an operation call 
if you can disregard the type of the non-dispatching parameters. Having to
consider their type just makes understanding more difficult.

Excluding overloading is reasonable for Eiffel but may not be for Ada. The 
reason I say this is that Eiffel is covariant and Ada avariant. As Jon pointed 
out, you may wish to use overloading to indicate that a 'covariant' operation 
does the same thing. Because in Eiffel such operations are truly covariant,
they are semantically related to their parent operations (by inheriatance)
and share the same name. So, Eiffel does not need overloading (for this 
purpose, at least).

Another related problem I see with overloading is that it is too liberal in
that it permits you to use a common name for completely unrelated operations.
Overloading can encourage you to be lazy by using an existing name instead 
of thinking of a more appropriate one. IMO, this freedom to name poorly
promotes obfuscation. 

:You are correct in saying that there is no semantic difference between
:unique names and overloading. 

Okay.

:However, just because there is no semantic
:difference don't suppose that it doesn't play a critical role in how the language
:is defined. 

Not sure what you mean here.

:By the way, consider what Eiffel does. It determines which routine is to be called
:based on the name of the routine and the type of one of the parameters. The only
:difference with Ada is that Ada uses all the parameters. 

Only in a special case, though.

:There is no semantic
:difference between determining statically or dynamically which method is invoked.
:When Eiffel compilers optimize away dispatching all they are really doing is
:static overload resolution. 

Yes, but this complexity is *hidden* form the user (as it ought to be).


Yes, a language is just a tool but a good tool will give you help where you
need it and this may mean curtailing your freedom where it will do you good.
An absence of overloading is a help rather than a hinderance, IMO.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au