🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.lang.eiffel
1 messages
1 total messages Started by day@grand.UUCP ( Wed, 21 Dec 1988 18:18
Re: Object oriented design or 'to inherit or not to inherit'
#17
Author: day@grand.UUCP (
Date: Wed, 21 Dec 1988 18:18
57 lines
3036 bytes
From: Dave Robbins <drobbins@gte.com>
Date: Tue, 22 Nov 88 08:58:31 EST

I think that the "defect" described by Jos is something that illustrates
the difference between inheritance of "specification" and inheritance of
"implementation."  The two are distinctly different concepts.

1) Inheritance of specification is inheritance of behavior, or protocol.
   A class inherits behavior from another class when it intends to behave
   the same way, and in such cases it is clearly expected that the subclass
   will respond appropriately to all the same operations to which the
   superclass responds.

2) Inheritance of implementation is no more and no less than a way to
   implement a class by sharing its implementation with that of another
   class.  A class that inherits for implementation purposes (such as
   FIXED_STACK in Jos' message) has absolutely no intention of behaving
   in all respects like the class from which it inherits.

It is easy to get the two concepts confused, especially when dealing with
languages that make no distinction between the two concepts of inheritance.
Off the top of my head, I don't recall whether or not Meyer in his book
draws such a distinction.  I do think that Eiffel is somewhat schizoid
about this: some of its rules (e.g., those for pre- and post-conditions
on redefined routines) are rather clearly intended to preserve behavior
in subclasses, thus supporting a specification-inheritance view, while
other rules (e.g., permitting a subclass to not export a feature exported
in the superclass) seem more in line with an implementation-inheritance
view.  The problem Jos points out is that FIXED_STACK intends to inherit
the implementation *but not the specification* of ARRAY.

In the class of object-oriented languages exemplified by Smalltalk, there
is no formal notion of specification at all -- inheritance is always
implementation inheritance.  In the class of object-oriented languages
exemplified by Eiffel, inheritance leans toward that of specification,
but retains implementation inheritance as well.  Trellis/Owl is the one
object-oriented language that I am familiar with that treats inheritance
strictly as inheritance of specification.

It is my opinion that the distinction between the two forms of inheritance
is very important, and that languages such as Eiffel must come to grips
with that distinction.  Eiffel has not, at this point, dealt effectively
with that distinction.  Both forms of inheritance are desirable, but the
two must not be inextricably intertwined.  A language must permit
inheritance of specification when that is desired, and inheritance of
implementation *but not specification* when that is desired.  Jan's
suggestion of "private" inheritance may have some merit.

I recall reading at least one or two papers in OOPSLA '87 that address
the two concepts of inheritance.

Enough for now.

Dave Robbins                    GTE Laboratories Incorporated
drobbins@gte.com                40 Sylvan Rd.
..!harvard!bunny!drobbins      Waltham, MA 02254
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads