Re: Rationale to close the operation overloading issue

>----- Original Message -----
>From: <Jochen.Ruetschlin@DaimlerChrysler.com>
>  . . .

>With an overload mechanism I can
> > express the fact, that the following operations are "instances" (not in an
> > implementational way but in a logical) of an operation providing one
>certain
> > functionality: returning an address of a person which is identified in
> > different ways.
> >
> > getAddress(socialNo)
> > getAddress(name, surname)
> > getAddress(login)
> > ...

These are clearly three different functions with three different 
semantics.  You may choose to think of them as being logically related, but 
that is purely a matter of your viewpoint.  It does not negate the fact 
that the three functions are different and do different things.  The 
compiler knows it, the function writers know it, and anyone using these 
functions needs to know it in order to use them.  It is true that some 
programming languages, as a syntactic shorthand, allow you to use the same 
name for these three functions, because the compiler is smart enough to 
disambiguate them later, from the types of their actual parameters.  But 
that is purely a notational convenience, and it comes at the cost of 
introducing ambiguity that must be resolved later when the code is processed.

I don't see a compelling need for overloading that would justify the 
ambiguity/complexity it adds.


-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Thursday, 20 June 2002 15:58:21 UTC