- From: Tom Jordahl <tomj@macromedia.com>
- Date: Fri, 21 Jun 2002 11:33:19 -0400
- To: "'David Booth'" <dbooth@w3.org>, "'Jochen.Ruetschlin@DaimlerChrysler.com'" <Jochen.Ruetschlin@DaimlerChrysler.com>
- Cc: "'www-ws-desc@w3.org'" <www-ws-desc@w3.org>
+1 -- Tom Jordahl Macromedia -----Original Message----- From: David Booth [mailto:dbooth@w3.org] Sent: Thursday, June 20, 2002 3:59 PM To: Jochen.Ruetschlin@DaimlerChrysler.com Cc: www-ws-desc@w3.org Subject: 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 Friday, 21 June 2002 11:33:52 UTC