Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.object
Subject: Re: How to use Inheritance instead of nesting
Message-ID: <5456@stpstn.UUCP>
Date: 11 Aug 90 18:52:56 GMT
References: <13647@shlump.nac.dec.com> <4800097@m.cs.uiuc.edu> <243@cadlab.sublink.ORG>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 63

In article <243@cadlab.sublink.ORG> staff@cadlab.sublink.ORG (Alex Martelli) writes:
>
>>In general, multiple inheritance is almost never needed.  I have never
>>seen a published example of a program using multiple inheritance
>>that couldn't be coded just as easily using components instead.  
>
>I have obviously not yet thought enough about these topics, but it
>seems to me they're deeply connected with the dual nature of class
>inheritance - inheritance of SPECIFICATIONS for an interface, and of
>IMPLEMENTATION... I would welcome a discussion on this, and of MI
>in general.

You and Cargil are on the money with this issue. There is so much
confusion about what OO really means because it seems to offer something
for the two traditional camps in software; those who believe software is
abstract, like mathematics (who like inheritance & static binding), 
and those who believe software is concrete, like engineering (who like
encapsulation and dynamic binding).

By supporting inheritance and encapsulation together, OOPLs are like a handsaw
(implementation tool) with a ruler (specification tool) taped onto the side.
The result is not totally ridiculous, for having both capabilities in
the same tool can be convenient for occasional (hobby) work. But the serious
craftsman realizes that specification tools and implementation tools are
tools for fundamentally different, but closely related, jobs, and builds
up astonishingly diverse collections of specification tools over here
and implementation tools yonder; together, but ever apart.

My IEEE Software paper (Nov 1990) goes into the distinction between 
specification and implementation in some detail, and argues that we must
stop relying so heavily on inheritance in our implementation tools, and
start devoting as much attention to creating specification tools as we
have on OOPLs. This doesn't mean ripping out inheritance from existing
OOPLs, but just knowing that the meaning of inheritance as supported there
is as an implementation tool, not a specification tool.

Where inheritance really belongs, and where it offers its greatest
potential, is in the (as-yet-nonexistent) specification tools; i.e.
specification language "compilers" that compile an input notation, the
specification, into but *tests*; executable code, or "gauges", that determine
(by testing) whether a given implementation is within tolerance to its 
specification.

In case this isn't obvious, the meaning I'm using for "specification"
includes not only *static* specifications (i.e. what method names/types
are listed in some interface file; i.e. class Stack has methods push and pop),
but *dynamic* specifications (i.e.  if I push 1,2,3 on an instance of class
Stack, pop should return 3,2,1).

Inheritance should work extremely well in this domain, far better than
it does in implementation languages. 

The problems with even simple single inheritance, which become vastly 
magnified with multiple inheritance, are why we never supported multiple
inheritance in Objective-C. Instead, we're focusing on providing multiple
inheritance where it might do more good than harm, in a parallel 
specification language, still under development.

Do you think we should call the new one Subjective-C? ;-)
-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482