Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!deimos.cis.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!kamin
From: kamin@m.cs.uiuc.edu
Newsgroups: comp.sw.components
Subject: Re: What should a component library loo
Message-ID: <71800003@m.cs.uiuc.edu>
Date: 1 Dec 89 01:26:06 GMT
References: <89@<DWIGGINS>
Lines: 43
Nf-ID: #R:<DWIGGINS:89:m.cs.uiuc.edu:71800003:000:2475
Nf-From: m.cs.uiuc.edu!kamin    Nov 30 08:46:00 1989


I'd like to repeat a point made by Ralph Johnson in an earlier notestring
that I think is very important.  In a sense, I believe that Ralph
and the other respondents are thinking of different things when they
say "specification."  Namely, there is a kind of specification *between*
"abstract, functional" spec. and "performance" spec.  There is
a spec. that includes the abstract, functional behavior *and* explicitly
gives its dependence on the spec.'s of the functions it calls.  The
reason this distinction is important is that in reusing code in
object-oriented languages, it is this latter kind of spec. that is
needed.

If you are talking about a data type (but non-oo) language, then
"reuse" means "being a client of", or "calling".  This kind of reuse
exists also in o-o languages, but the interesting kinds of reuse
are those you get by redefining methods *and thereby changing the
semantics of other methods you use.*  Thus, we need a specification
that not only says what a method m does, but says how your redefinition
of some other methods will alter what m does.  (One way to think of
this is that each method has all the other methods it calls as
implicit arguments;  the specification must give the meaning of the
method as a function of *all* its arguments, including the implicit
ones.)  In principle, this is just an "abstract, functional" spec.,
but in practice it is a much more complicated thing.  I believe
that Ralph's earlier point about programs as specifications
might be restated as "You are unlikely to find that a spec.
in this o-o sense will be significantly simpler than the code."

This has some bearing also on the current argument about multiple
implementations of a single spec.  I think Ralph is saying that in his
experience in Smalltalk, this doesn't happen much.  However, what *does*
happen a lot is that a class is inherited and modified (by subclassing).
In other words, in this context, one has a spec. (if at all), not in
order to give multiple implementations that vary in *performance*, but
rather to give multiple implementations that vary in *semantics*.  Of
course, from a traditional specification viewpoint, this last
assertion is nonsensical - if the semantics are different, it is,
by definition, *not* an implementation.  Still, I believe this is the
basic philosophical position that Ralph is coming at this thing from,
and perhaps this may help dispel some confusion.

Sam Kamin
Univ. of Illinois at Urbana-Champaign