Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!ucsd!hub.ucsb.edu!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.object
Subject: Re: OO Ada -- another way
Message-ID: <443@eiffel.UUCP>
Date: 7 Nov 90 05:59:14 GMT
References: <90@<PCG> <77500062@m.cs.uiuc.edu>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 61

From <77500062@m.cs.uiuc.edu> by johnson@m.cs.uiuc.edu (Ralph Johnson):

> The real problem is not that inheritance is a poor way to reuse 
> implementation, but that it is a poor way to reuse specification.
> In my opinion, subclassing has little to do with subtyping.  Languages
> like C++ or Eiffel that tie them together then have to struggle with
> the problems that this creates.  This causes programmers to create
> abstract classes only to get around problems caused by the type checker.


	Let me disagree. What I find exciting about inheritance is
precisely that it is two mechanisms combined into one: a module
reuse mechanism and a subtyping mechanism.

	This is of course a natural consequence of the view that a class
is two things: modular facility and type. This view is applied
to its full extent in Eiffel, where there is no other modular facility
than the class, and every possible type is based on a class. The
rules applying to inheritance (e.g. information hiding rules, the
covariant conventions for typing etc.) follow directly.

	The above two purposes of inheritance are not equally useful in
all cases. Sometimes you want inheritance exclusively as a way
to reuse the facilities of an existing module (as when you inherit
from the Eiffel library classes EXCEPTIONS, which enables the authors
of descendant classes to adjust the exception handling mechanism to
their specific needs, or MEMORY, which gives them facilities for
fine-tuning garbage collection and memory management). At other times,
you will use inheritance solely for subtyping, as when defining
FILE as an heir to DEVICE. In many cases, however, you want a little
of both. A typical example is the library class STORABLE, used to make
object persistent (storing and retrieving entire object structures):
this may be viewed both as a ``library'' of persistence facilities,
and as the abstract data type describing persistent object
structures. 

	I do not understand Professor Johnson's last comment about
creating abstract classes ``only to get around problems by the
type checker''. This does not relate to anything in my experience.
In fact, I have often heard objections to static typing (often from
people used to programming in Smalltalk, Objective-C or C++) based
on the argument that strong typing limits the expressive power
of object-oriented programming. Whenever I have tried to go further
and understand the real problem, it has turned out that the claimed
counter-examples (in which typing constraints were supposed to be an
obstacle) only existed because of the absence of one or more of

	(a) multiple inheritance 
	(b) genericity
	(c) reverse assignment attempt 

and could be handled quite elegantly, with typing constraints
fully in force, as soon as these mechanisms were available.

	I do not know, of course, what Professor Johnson really has
in mind, but if anyone has a good ``impossible case'' for typing
I would be glad to see it discussed on the net.
(Yes, this is a challenge.)
-- 
-- Bertrand Meyer
bertrand@eiffel.com