W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2002

Re: Rationale to close the operation overloading issue

From: <Jochen.Ruetschlin@DaimlerChrysler.com>
Date: Mon, 24 Jun 2002 15:45:47 +0200
To: <dbooth@w3.org>
Cc: <www-ws-desc@w3.org>
Message-ID: <0057440019586359000002L492*@MHS>

> > > 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.

If so, this would mean that the following add methods are also semantically 
different:

  add(int, int)
  add(unsigned int, unsigned int)
  add(int, float)

I'm not sure, if most people would agree on that.

Yes, from the perspective of an compiler its true, that there are (different) 
implementations for each method (with different addresses to jump on in the 
memory ...). But IMO we are speaking about interfaces and operations (not 
methods), and I still believe that this is one operation with one meaning 
(semantics = meaning/understanding of something).


jr. 

Jochen Rütschlin
DaimlerChrysler · Research and Technology
Data and Process Management (RIC/ED)
P.O. Box 2360 · D-89013 Ulm (Donau) · Germany
Visitor's address: Wilhelm-Runge-Straße 11
Phone:   +49.731.505-2830
Telefax: +49.731.505-4401
Internet E-Mail: jochen.ruetschlin@DaimlerChrysler.com
Internet: 
http://www.informatik.uni-stuttgart.de/ipvr/as/personen/ruetschlin.html 
Received on Monday, 24 June 2002 09:46:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:20 GMT