On 04-Nov-1998, Michael Hobbs <[EMAIL PROTECTED]> wrote:
> "S.D.Mechveliani" wrote:
> >
> When considering changes to a language, I think one needs to carefully
> measure the difference between convenience and necessity/correctness. I
> think everyone will agree that ad hoc polymorphism (aka overloading) is
> very _convenient_ but I don't think that everyone will agree that it is
> the _correct_ thing to do. I know a few OO purists who will insist that
> overloading is a Bad Thing. Their reasoning: If a function does similar
> things, but with different types, define the function in terms of a
> common base class.
Agreed (at least in the context of Haskell).
> If two functions do radically different things, but
> happen to be named the same, you have a naming problem. One of the
> functions should change its name.
This reasoning is flawed. These two functions or two constructors
may be defined in different modules, for example.
What's the naming problem? The only problem is that Haskell compilers
complain. Human readers can tell which name is meant from the context,
and so could Haskell compilers, if the Haskell language allowed it.
> There are some weaknesses in this rationale. One is the existence of
> homonyms in natural languages. For instance, the word "product" is a
> perfectly good name for two functions that do very different things.
Yep.
> Perhaps a "better" solution than ad hoc polymorphism would be to provide
> a more convenient namespace syntax. Am I mistaken in thinking that
> overloading, for overloading's sake, isn't what is wanted; what is
> wanted is to be able to easily differentiate between two functions that
> happen to be named the same?
Why should I have to explicitly differentiate if the meaning is clear
from the context?
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
