Re: Eiffel and Java

[fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)]

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.