🚀 go-pugleaf

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