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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC 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: fdb77,953e1a6689d791f6
X-Google-Attributes: gidfdb77,public
X-Google-Thread: 103376,953e1a6689d791f6
X-Google-Attributes: gid103376,public
X-Google-Thread: 1108a1,6806d4da9f37ac7c
X-Google-Attributes: gid1108a1,public
From: shang@corp.mot.com (David L. Shang)
Subject: Re: Eiffel and Java
Date: 1996/11/18
Message-ID: <1996Nov18.180520.12596@schbbs.mot.com>#1/1
X-Deja-AN: 197421020
sender: news@schbbs.mot.com (SCHBBS News Account)
references: <56j7up$h1n@mulga.cs.mu.OZ.AU>
organization: MOTOROLA 
reply-to: shang@corp.mot.com
newsgroups: 
 comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object
Date: 1996-11-18T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <56j7up$h1n@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus  
Henderson) writes:

> shang@corp.mot.com (David L. Shang) writes:
> >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;
>

Here you evaded the question. It is not the separation but the
delegation in your example that helps the reduction of the
dependency. Transframe supports automatic delegation: you are
not necessary to delegate all the methods manually. Just write:

	class C is A by B;

Separation is not necessary. B is subtype of A; C is subtype of
A; but C is not subtype, nor subclass of of B.

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

Again, you miss the nail head. The purpose of Sather's separation
is not for the reduction of dependency, but for allowing subclass
to have covariant constraints, i.e. to have presumptions that violates
the specification in its parent class. 

Using delegation manually in C++ and Effel, you can reduce
the dependency in the same way as you did in Sather.

David Shang