Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: johnson@m.cs.uiuc.edu
Newsgroups: comp.object
Subject: Re: How to use Inheritance instead
Message-ID: <77500053@m.cs.uiuc.edu>
Date: 13 Aug 90 15:24:00 GMT
References: <5456@stpstn.UUCP>
Lines: 34
Nf-ID: #R:stpstn.UUCP:5456:m.cs.uiuc.edu:77500053:000:1776
Nf-From: m.cs.uiuc.edu!johnson    Aug 13 10:24:00 1990


Brad Cox says:
>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.

I agree that inheritance as supported in current languages is more of
a implementation tool than a specification tool.  That is why Typed
Smalltalk separates types and classes.  Types are specification and
classes are implementation.  Instead of class inheritance, the type
system uses type inclusion.

I disagree with Brad in that I place a much greater emphasis on static
specifications than he does.  Perhaps this is because I'm an academic.
Types in Typed Smalltalk only let you prove that the value of a variable
understands certain messages, or is in a certain class.  However, I am
interested in enhancing it so that more can be said about a program.
In particular, I think that Brad's example with stacks (if I push 1,2,3
on an instance of class Stack, pop should return 3,2,1) is the sort of
thing that should be done statically.

Both testing and static checking are important.  However, my basic
philosophy is
	"Never put off until run-time what you can do at compile time."
which is a quote from David Gries's compiler book.  Of course, being
a Smalltalk programmer, my definition of what you can do at compile
time is significantly different from Gries's, but I agree with him on
this point.

Ralph Johnson - University of Illinois at Urbana-Champaign