🚀 go-pugleaf

In article <71800004@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson)
writes:
>I think that Paul Sander's B-tree abstraction is a pretty good
>reusable component.  However, I think that Bill Ogden has a
>good point.  Bill's basic point is that it is really more
>important to reuse specifications than it is to reuse
>implementations.  Of course, we need to provide implementations
>for our specifications, but the user should think mostly of the
>specification and not the implementation.  B-trees are an
>implementation, while almost-constant functions are specification.

I was under the impression that a major reason for inventing reusable
components was to reuse code, that is to recycle implementations.
A clean, well-documented interface is a tool that encourages using a
piece of existing code rather than rewriting it.  Producing a set of
components with uniform (or nearly so) interfaces will hopefully flatten
the learning curve for that particular set of tools, encouraging
reuse of several components in that set.  Documenting all of the
components of that set in the same place will increase the chances
of discovery of a piece of code.

I believe, however, that reusing specifications for their own sake
is of limited value.  Though it is possible to write several implementations
of, say, an almost-constant-function (e.g. B-tree, doubly-linked list,
splay tree, etc.), each implementation has strengths, and implementation
details that could be very useful if they are presented in the interface.

Is the direction of the development of reusable software components really
toward interchangeability?  Is that really necessary?  Why would I want to
simply unplug a B-tree and plug in a doubly-linked list in its place?  Or
vice-versa?  Performance reasons, perhaps, but making minor changes to the
"glue" code surrounding the calls to the components doesn't add much to
relinking.  But other than performance characteristics, why would someone
want to keep multiple implementations of a specification, or multiple
implementations of an almost-constant-function?  If one does the job
just as well as the other, why have both?

>Further, I take the point of view held by the object-oriented
>community that it is not particular kinds of components that are
>important, but rather sets of components and their relationships.
>The advantage of concentrating on specification is that you end
>up with lots of components that share the same specification.
>When you learn one, you have learned something about all of them.
>Also, it becomes easier to replace one component with another
>because they will share specification.  Thus, it becomes easier
>to write utilities that work with any of the related components.

One of the major selling points of object-oriented anything is that
when refining something to make something else, the properties of
the original thing are inherited automatically by the new thing, and
those properties are incrementally changed by the new thing.  In
practice while programming, it turns out that the interfaces of the
two objects may be the same, but the objects are hardly interchangeable,
since their semantics are different.  They may not even be compatible in
the sense that one can replace the other in some section of code.

In any case, the inheritance mechanism is simply an automatic way
for a new object to reuse the implementation of another in all except
those features that are different from its predecessor.
-- 
Paul Sander        (408) 734-9822  | "Passwords are like underwear," she said,
paul@Atherton.COM                  | "Both should be changed often."
{decwrl,pyramid,sun}!athertn!paul  | -- Bennett Falk in "Mom Meets Unix"