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

[donh@syd.csa.com.au (Don Harrison)]

Bill Williams writes:

:Which set of parentheses, 1st or 2nd?

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? 

I'll attempt to clarify what I'm saying. It is simply that Ada and Eiffel
offer different rules for selecting the polymorphic operation. The following 
table hopefully summarises the essential differences between the two schemes:

                           Ada                         Eiffel
--------------------------------------------------------------------------------

1) How selected?           Implicit                    Explicit

2) Which selected?         Same signature except for   Redefines clause (+ optional
                           dispatching parameter       select clause for repeated
                                                       inheritance)

3) Selection choice?       No                          Yes

4) Safe?                   Yes                         Yes (if supported by static
                                                       validity rules); No (if not)
5) Other operations        Yes (if has same name)      No (must have different name)
   overloaded?

In the case of Ada, any operation that happens to have the same name as the
polymorphic operation will happen to be overloaded. This has no effect on the 
semantics of polymorphism. I hope this clarifies the issue. If still unsure, 
re-read my post containing the example comparing Ada and Eiffel plus the addendum 
about repeated inheritance.

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

Perish the thought. :)

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

This is basically what I have in mind except that 'add_complex' may just be
called 'add'. Something like:

  - Class NUMERIC contains an 'add' operation for NUMERICs
  - Class NUMERIC has heirs COMPLEX and REAL.

  - Class REAL redefines 'add' covariantly to add REALs

  - Class COMPLEX redefines 'add' covariantly to add COMPLEXes
  - Class COMPLEX defines an 'add_real' to add COMPLEX and REAL.

(Details omitted to protect the innocent).
  
: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.

Yes, I've noticed you have a few. :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au