Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!cs.uiuc.EDU!johnson
From: johnson@cs.uiuc.EDU (Ralph Johnson)
Newsgroups: comp.object
Subject: Redefining (used to be Void references)
Message-ID: <1990Nov17.174653.6291@ux1.cso.uiuc.edu>
Date: 17 Nov 90 17:46:53 GMT
References: <454@eiffel.UUCP> <1990Nov15.011702.25087@Neon.Stanford.EDU> <11113@pt.cs.cmu.edu> <1990Nov16.065609.15460@tukki.jyu.fi>
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: johnson@cs.uiuc.EDU (Ralph Johnson)
Organization: University of Illinois
Lines: 46

In article <1990Nov16.065609.15460@tukki.jyu.fi>, sakkinen@tukki.jyu.fi (Markku Sakkinen) writes:

|> In my opinion, inheriting only parts of superclass, say C,
|> into a subclass, say D, is a highly dubious idea even for this purpose.
|> One should rather have defined a fully-fledged class B containing
|> those parts first, then both C and D as subclasses of B.
|> It would be nice to have the kind of generalisation facilities
|> that Claus Pedersen suggested in his OOPSLA'89 paper:
|> that one could derive _super_classes approximately as easily
|> as existing languages allow us to derive _sub_classes.


Before I start agreeing with Markku (which is always boring) let me
disagree a little.  When you are prototyping, you often care more about
the behavior of a program than its structure.  Thus, prototypers want
to get something working quickly, and don't care what it looks like.

However, the kind of program resulting from prototyping this way should
never be mistaken for elegant programs.  I rewrite code that results
from prototyping to make it elegant, and the rewriting often splits up
classes just the way Markku says.

I think that the conflict between getting something to work quickly and
making it elegant could be lessened with better programming environment
support.  We need tools that would split up classes and derive new
super classes from exisiting classes.

Following the Scandianvian tradition, a program provides a model of
some system.  When you find that you need to reuse just part of a class
then it means that your model was wrong.  Instead of patching up the
code, you should fix your model.

Sometimes people argue against this point of view by saying that
it isn't possible to revise the class hierarchy because the source
code is not available, or they will say that this is going against
reusable software because instead of reusing a class we are revising
a class.  Naturally, I disagree strongly with these points of view.
The first point is just a good reason why source should always be
avaliable, and the second shows that wrong definitions of software
reuse are being applied.  If you believe that the main purpose of a
program is as a model of a system, and that it is just as important
for a program to be a way of communicating between people as it is
for it to be a way of communicating with machines, then changing the
model is absolutely necessary when it is shown to be inadequate.

Ralph Johnson -- University of Illinois at Urbana-Champaign