From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,953e1a6689d791f6
X-Google-Attributes: gidfac41,public
X-Google-Thread: fdb77,953e1a6689d791f6
X-Google-Attributes: gidfdb77,public
X-Google-Thread: 103376,953e1a6689d791f6
X-Google-Attributes: gid103376,public
X-Google-Thread: f79bb,953e1a6689d791f6
X-Google-Attributes: gidf79bb,public
From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Subject: Re: Eiffel and Java
Date: 1996/10/30
Message-ID: <558296$aqk@mulga.cs.mu.OZ.AU>#1/1
X-Deja-AN: 193342926
references: <55562c$nkd@mulga.cs.mu.OZ.AU> <E02t77.JJu@syd.csa.com.au>
organization: Comp Sci, University of Melbourne
newsgroups: 
 comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy
Date: 1996-10-30T00:00:00+00:00
List-Id: <comp.lang.ada>


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

>Fergus Henderson writes:
>
>:donh@syd.csa.com.au (Don Harrison) writes:
>:
>:>What is the purpose of separating interface and implementation inheritance? 
>:
>:Suppose I have two existing library classes (perhaps supplied by different
>:vendors) which have some commonality, but don't inherit from a common
>:base class.  In Sather, one can simply create a new interface and
>:declare these classes to be instances of this interface, without
>:modifying the existing code.
>
>Sorry. Don't follow. Can you give an example?
>Isn't this creating a superclass rather than separating interface and 
>implementation inheritance?

Yes, that is creating a superclass.  However, I think it would be
impossible to provide this feature in a language like C++ where
interface and implementation inheritence are combined.

The following is from Stephen Omohundro's article about Sather in Dr. Dobb's:
======================================================================
Separate Implementation and Type Inheritance 

In most object-oriented languages inheritance both defines the subtype
relation and causes the descendant to use an implementation provided by
the ancestor. These are quite different notions and confounding them
often causes semantic problems. For example, one reason why Eiffel's
type system is not statically checkable is that it mandates "covariant"
conformance for routine argument types (Meyer, 1992). This means that a
routine in a descendant must have argument types which are subtypes of
the corresponding argument types in the ancestor. Because of this
choice, the compiler cannot ensure argument expressions conform to the
argument type of the called routine at compile time. In Sather,
inheritance from abstract classes defines subtyping while inheritance
from other classes is used solely for implementation inheritance. This
allows Sather to use the statically type-safe contravariant rule for
routine argument conformance.
======================================================================

The following is from Benedict A. Gomes' Sather tutorial.
======================================================================
What is the rationale behind supertyping clauses, and how are they used ? 

You define supertypes of already existing types. The supertype can only
contain routines that are found in the subtype i.e. it cannot extend
the interface of the subtype.

        type $IS_EMPTY{T} > FLIST{T}, FSET{T} is
           is_empty: BOOL;
        end;

The need for supertyping clauses arises from our definitition of
type-bounds in parametrized types. Any instantiation of the parameters
of a parametrized type must be a subtype of those typebounds. You may,
however, wish to create a parametrized type which is instantiated with
existing library code which is not already under the typebound you
want.  For instance, suppose you want to create a class FOO, whose
parameters must support both is_eq and is_lt. One way to do this is as
follows:

 
class BAR{T}  is
        -- Library class that you can't modify
   is_eq(o: T): BOOL;
   is_lt(o: T): BOOL;
end;
type $MY_BOUND{T} > BAR{T} is
    is_eq(o: T): BOOL;
    is_lt(o: T): BOOL;
end;
class FOO{T < $MY_BOUND{T}} is
   some_routine is
        -- uses the is_eq and is_lt routines on objects of type T
        a,b,c: T;
        if (a < b or b = c) then
                ..
        end;
  end;
end;

Thus, supertyping provides a convenient method of parametrizing
containers, so that they can be instantiated using existing classes.
======================================================================

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.