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

[bill.williams@gecm.com]

donh@syd.csa.com.au (Don Harrison) writes:

> However, in relation to Eiffel, I'm saying that it has no *need* of an 
> overloading mechanism because it is redundant due to the availability of 
> covariance. An operation which you might choose to implement in Ada by 
> overloading an inherited one (because they do the same job), you would 
> implement in Eiffel as an overriding operation because it belongs in the 
> same inheritance hierarchy (according to Eiffel's scheme of things).
> 
> [Before half the world disputes the latter part of this sentence, kindly note 
> the qualifier in parentheses].

Which set of parentheses, 1st or 2nd?

I'm not sure I understand what you're saying here. Can we try an
example so you can tell me that I've got the wrong end of the
proverbial stick? 

Suppose I write a complex number class (gosh, how original) and I
define all the normal arithmetic operators. In Ada I can overload
these operators to define 
  <complex> + <real> 
as well as 
  <complex> + <complex>
[I can do it in C++ as well, but we won't mention that...]
You seem to be suggesting that in Eiffel I need to define a class
which inherits from complex and defines interactions with reals. But
even this doesn't work. If I have a variable which is of the
complex class I can't add reals to it. If it's of the interaction
class, then I can't add complex's to it. The only solution Eiffel
offers me is to define 'add_complex' and 'add_real' members to the
complex class. While this achieves the functionality I need it falls
way short in terms of ease of maintenance when 'programming in the
large' IMO.

Sorry, you've prodded one of the bees in my bonnet w.r.t Eiffel and I
just couldn't let this one go by.

Cheers
Bill
-- 
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!

bill.williams@gecm.com
Tel: +44 1245 242016
Fax: +44 1245 242003