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

[jsa@alexandria (Jon S Anthony)]

In article <E0J2vy.E6C@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> 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

The real world has nothing to do with it.  What is "modelling
integrity" anyway?


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

Things in the world aren't specific or general at all.  That is an
artificial organizational constraint applied in the semantics of some
modeling schemes (taxonomic...)  You really must separate the world
from the formalism or you will never get anywhere.


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

Well, in a covariant model.  But why think that is all there is or
even that it is the best????  There's just no evidence for it.


> 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

How did you arrive at that conclusion??  No, it simply dispatches to
the operation for which the arguments are intended.  If it is to the
more general, well then that is because the operands passed _are_ of
the more general type!


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

Well, I disagree, because you are just plain factually wrong.


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

No, you are not "re-inventing" anything.  You aren't overloading for
those reasons at all.  You overload because a) the inherited operation
is not refined in the "other" parameter and that is what you want and
b) using a different name for the operation is confusing, misleading,
and leads to poor software maintenance.  Which simply says, you can
have your cake (complete safety) and eat it too (give the programmer
model the functional equivalence of unbroken covariance).
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com