🚀 go-pugleaf

Since several people have misunderstood my position, I guess I didn't
describe it very well.  I am strongly in favor of separating specification
from implementation as much as possible.  My complaint was against the
claim that one of the main reasons for separating them was so that
each specification could have a set of implementations, each of which
had different performance characteristics.  My observation is that,
except for general purpose data structures, there doesn't seem to be
much need for a component to have a variety of implementations that
vary in performance characteristics.

In my opinion, the idea that specification whould be separated from
implementation is a "motherhood" issue that needs no defense.  I am
arguing against a particular use of this idea, not the idea itself.

Part of the problem comes from different meanings of "specification".
I most certainly do NOT use the Ada notion of an interface specification.
That is just type conformance.  Since I push polymorphic languages, i.e.
object-oriented languages, I naturally think that it is essential to have
many components with the same type.  However, I think of "specification"
as defining the behavior of a component, not just barely enough to
type-check programs.

As an example, object-oriented user interface systems usually assume
that each object can display itself and can respond to actions by
the user.  Thus, each user interface object has a "display" and a
"mouse clicked" operation.  If you consider the set of operations
that an object will perform to be its specification, then all the
user interface objects have the same specification.  However, menus
respond quite differently from buttons to mouse motion and mouse
button presses.  Thus, I'd say that they have completely different
specifications.  I'd consider two objects to have different specs if
they looked at all different on the screen.  Thus, different kinds of
menus would have different specifications, although they would look
pretty much the same to the application program, and one could easily
be replaced by another.

Ralph Johnson