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

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

I wrote:

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

These comments are made in the context of the example Jon Anthony and I
discussed. The different schemes of Ada and Eiffel might be demonstrated 
by expanding the example Jon and I were discussing.

Assuming types A and B with heirs C and D repectively. Consider the following
operations:

Ada                                        Eiffel
---                                        ------

A's operations
op (a: A; b: B'Class)                (1)    In A: op (b: B)                  (4)

B's operations
op (c: C; d: D'Class)  -- overloaded (2)   In C: op (d: D)      -- overrided (5)
op (c: C; b: B'Class)  -- inherited  (3)   In C: new_op (b: B)  -- new       (6)

What we see is that Ada has taken the safe approach of diverting polymorphism
down the avariant path (3). The specialised op (2) becomes an overloaded 
operation and is no longer polymorphic wrt (1). Note that (3) is more general
than (2).

On the Eiffel side, polymorphism continues down the line of specialisation
(true covariance) so that (5) is polymorphic wrt (4). The more general (6)
is a new operation.

Now the contentious part. :(  The issue of which model is 'correct' depends on
which operation of B can better be regarded as functionally equivalent to 
the operation in A. (The safety issue is secondary, IMO - I'm talking about
modelling integrity). What seems to happen in the real world is that as
interactions between things become more specific, the things involved become
more specific as well (or some may stay the same). (The things do not become
*less* specific, but that is another matter). To model this faithfully,
you would need multiple dispatching but for most purposes, you can use use the
simpler (but lop-sided) model of single dispatching. But the important thing
is that we need to cater for the situation of both things becoming more
specific. If we don't, then what we end up with is specialisations that are
lop-sided and are capable of modelling only the special case where only one
thing becomes more specialised. (This is what happens in Ada).

I think the choice in Eiffel of making specialisations functionally equivalent
to their generalisations is the right one in terms of modelling integrity.
The downside is having then to deal with the non-trivial problem of breaking
polymorphism. :(  By comparison, the Ada model is completely safe, but it
sacrifices modelling integrity to acheive it, IMO.


Juergen Schlegelmilch wrote:

:Hm, being not too familiar with Ada, I may be wrong, but in the subclass
:you have both operations available, while with Eiffel's redefinition you
:only have the redefined but not the inherited (unless you inherited once,
                                                                     ^^^^
                                                                     twice?

:but then you have to rename). Thus, in a piece of code where an operation 
:is applied to arguments suitable only for the inherited version, Eiffel 
:will signal a type error (system validity or by runtime crash :-), 

IMO, this is what ought to happen because because the operation has become 
more specific and so requires more specific parameters. The parameter 
combination provided is invalid, so the runtime system (correctly) raises an 
exception. This highlights the fact that there is an error in the client which 
must be fixed. If a more general operation realy *is* required, then you can 
define a *new* operation [(6) in my example] for this purpose. So, Eiffel 
dispatches to a more specific operation by default rather than to a more general 
one. This differs from Ada which ...

: will use the inherited (overloaded) version.

So, Ada dispatches to a more general operation by default rather than to a 
more specific one. This is the wrong way round, IMO. I think calling a more 
general operation ought to be the exception rather than the default. Some will 
not agree with me but that's okay. :)

:So, covariant redefinition is not a mechanism to implement/simulate 
:overloading.

Just as well I didn't say that then. :)

I *am* saying that because Eiffel is covariant, you don't have to re-invent
an operation as an overloaded operation due to inheriting some unwanted 
baggage that no longer reflects the specialisation of an abstraction. 


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