Re: Eiffel and Java + Ada dispatching

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

Jon S Anthony writes:

:In article <E06F2B.Az7@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
:
:> Jon S Anthony writes:
:> 
:> :> 2) but this is combined with the static overloading inherited from
:> :> Ada83; which is merely syntactic sugar for routine having
:> :> (statically) different signatures.
:> :
:> :Criminey!  This is wrong too.  It is not "merely syntactic sugar", as it
:> :is part and parcel of why Ada does not need any system validity checks!
:> 
:> Disagree. Overloading *is* syntactic sugar because it merely allows reuse
:> of an identifier without any semantic difference (to using a different one). 
:> The reason Ada does not need checks on use of polymorphism is that 
:> it is avariant (no variance) compared with Eiffel which is covariant.
:
:Go back and re-read that long note I wrote in the "Real OO" thread on
:why Ada does not have system validity problems and then the follow up
:which tried to point out your misunderstandings and you will see why
:you are wrong about this.

I was able to infer from your note why Ada you cannot break polymorhism.
(Broken polymorphism is the problem in Eiffel - System Validity it's solution).
The reason is that Ada is avariant - when overriding dispatching operations,
you cannot redefine non-dispatching parameters covariantly.

eg. Assuming type B descended from A and Q descended from P,

1.  procedure op (a: A; p: P'Class);     -- dispatches on a
    ...
2.  procedure op (b: B; p: P'Class);     -- dispatches on b (overriding op above)

But, as you point out below, a dispatching operation that has the same 
signature as another but a different non-dispatching parameter does not 
override the original, so cannot be called polymorphically wrt the original.

3.  procedure op (b: B; p: Q'Class);     -- dispatches on b (distinct operation from
                                         -- 1. above - does not override it).

What we can see from this is that overriding in Ada is implied (by the 
combination of descendant dispatching parameter, same non-dispatching parameter) 
rather than being explicit as in Eiffel (redefine clause).

:The reason that OL enters into the puzzle is that it allows for the
:definition of _new_ operations (on specific types) with descendent
:controlling parameter(s) and a _non_ controlling descendent
:parameter(s) but with the same name.  Now you can claim that this is
:"confusing" (a value judgement), but that will most likely be because
:you are not used to the differentiation between specific types and
:class-wide types ...

Yes. I agree this may be confusing to some. I was one of them. :) 
Personally, if writing Ada, I would prefer to use a different name rather 
than overloading the old one to remove all confusion.

4.  procedure new_op (b: B; p: Q'Class);   -- dispatches on b



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