Re: Eiffel and Java

[mernst@x4u2.desy.de (Matthias Ernst)]

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

: Why does Sather use contravariance (apart from the safety issue). You would 
: expect more specific actions to require more specific parameters.

: : Sather also allow sepation between code inclusion and 
: :subtyping. Is it cleaner, or just more complicated that the universal 
: :inheritance mecanism ? any comment ?)

: What is the purpose of separating interface and implementation inheritance? 
: When would you need to inherit an implementation without needing it's interface 
: as well (and vice versa)?

All languages that unify inheritance and subtyping enforce that once you
inherit from a class you build a subtype. There are several examples (mostly
with binary methods and the type Self, SAME, like Current or whatever) that
show that it may be the implementation you are interested in but you can't
guarantee subtype relationship.

Say:
class Comparable
is
  "<="(other: Self): Bool is abstract;
  ">="(other: Self): Bool is other <= self end;
  ">"(other: Self): Bool is ~(self <= other) end;
  "<"(other: Self): Bool is other > self end;
end;

You are likely interested to inherit from this class and only implement "<="
but as we all know subtyping is impossible because of the contravariant
position of the Self parameters.

When you look at the examples that claim for covariance you will see that
many are not interested in subtyping, i.e. subsumption, but gather advantage
only from code reuse.

There are already many publications about this topic, you may want to search
for 'binary methods', 'inheritance is not subtyping', 'type matching',
'F-bounded subtyping' and so on. Look for Kim Bruce, Cardelli, Castagna and
many more.

As far as I understand it correctly, it is about what Eiffel's new
typechecking rules with respect to 'polymorphic catcalls' express:
'If it serves your purpose  you may, while inheriting, change parameters or
variable types or access rules in an incompatible (i.e. subtype breaking)
way. But if you try to use subsumption I (the typechecker) will catch you,
requiring programm data flow analysis.'

Sather says:
'You may change what you want when inheriting since for subsumption you must
separately obey the subtype relation that I can check locally.' which I like
better.

One should not forget that Sather's rules also have disadvantages. Because
of the freedom you have it's nearly impossible to check routines once in the
superclass and then inherit them unchecked. The Sather compiler must recheck
every inherited routine in the context of its new class.


-- Matthias