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: f79bb,953e1a6689d791f6
X-Google-Attributes: gidf79bb,public
X-Google-Thread: 103376,953e1a6689d791f6
X-Google-Attributes: gid103376,public
X-Google-Thread: fdb77,953e1a6689d791f6
X-Google-Attributes: gidfdb77,public
X-Google-Thread: 1108a1,6806d4da9f37ac7c
X-Google-Attributes: gid1108a1,public
From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Subject: Re: Eiffel and Java
Date: 1996/11/16
Message-ID: <56j7up$h1n@mulga.cs.mu.OZ.AU>#1/1
X-Deja-AN: 196771480
references: <5694r8$c9c@mulga.cs.mu.OZ.AU>
 <1996Nov12.143451.16691@schbbs.mot.com>
organization: Comp Sci, University of Melbourne
newsgroups: 
 comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object
Date: 1996-11-16T00:00:00+00:00
List-Id: <comp.lang.ada>


shang@corp.mot.com (David L. Shang) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>> shang@corp.mot.com (David L. Shang) writes:
>> > But separation subtype from subclass is not [good].
>> 
>> Why not?  Doesn't this also serve to "reduce the dependency
>> among software components"?
>
>No, the separation subtype from subclass does not help
>dependency reduction. Let "A" be a parent class, and "B" be
>a subclass but not a subtype. "C" cannot use "B" unless it is
>dependent on "B", because depending on "A" does not provide
>any polymorphism that can guide the implementation to "B".

In this situation, a Sather programmer would make an interface $A
that was a supertype of B, and then C could use B via the $A interface.

	interface $A > B is ...  end;

	class C < $A is
		private include B;
		...
	end;

If you want the compiler to make sure that C does not depend on B,
you can encapsulate the dependency on B as follows:

	class C_A < $A is private include B end;

	class C < $A is
		private include C_A;
		...
	end;

Later another programmer could change things so
that C used any other class B2 < $A instead of B,
just by changing the one-line definition of C_A.

This seems much better than languages such as C++ or Eiffel which don't
separate subtype and subclass inheritence, where a programmer would
probably make C access B via A rather than $A.  If A is not an abstract
interface, this makes it difficult to change the program to use a
different implementation.

So I think separating subtype from subclass does serve to
reduce the dependency among software components.

>> ]In Sather, implementation classes are not always subtype of the
>> ]parent class. They merely reuse the code (inherite the implementation)
>> ]defined in their parent, but not necessarily be subtype of it.
>> ]Without subtyping, the interface provided in the parent cannot
>> ]serve as a polymorphic interface for all the implementations.
>> 
>> Yes, and that's a good thing, isn't it?
>> It decouples the interface and the implementation,
>> making it easier to use a different implementation.
>> 
>As I stated above, it does not make it easier to use a different
>implementation,

I think it does.  Requiring people to use only abstract interfaces
for polymorphism does make it easier to use different implementations.

>rather, it makes it easier to create a
>different implementation that is not a subtype, or that
>violates the parent's regulation.

If you said "as well" rather than "rather", then I might agree with you.

But I'm not yet convinced that creating a different implementation that is
not a subtype is necessarily a bad thing, in a language which separates
subtyping and subclassing.

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