🚀 go-pugleaf

Bill Wolfe is right -- I believe the following two things:
      1) It is fairly unlikely that any particular component will
           fit the application developer's requirements, hence they
           must be rapidly modifiable as with inheritance.  For some
           reason, using a tool which automatically constructs a
           higher level of abstraction (for appropriate modification)
           isn't appropriate, even though this also isolates the 
           specification from the implementation.

      2) For some reason, run-time binding is necessary.

As far as the third goes, I think that diddling with old code
is a necessary evil, but should be avoided where possible.  We
need to make reuse systems that let us leave old code along.

>   ...  In general,
>   either a component is readily available (mostly the case), or it
>   gets invented on the spot.  

That's because you have no alternative.  Inheritance makes a new
alternative, invent a component by reusing most of the design of
an existing one.  I find that user interface tool-kits provide 95%
of the components that I need.  In a small program, they might
provide everything I need.  However, in a large program most of
my time goes to building the 5% of the components that don't exist.
Inheritance makes that 5% easier.

>   Furthermore, in the very unlikely event 
>   that I need to slightly modify an existing ADT, a tool can be used to
>   generate another level of abstraction and proceed from there. 

As I said before, I think that this is a good idea.  It is essentially
inheritance.
  
>   I don't perceive any need for run-time binding.

Consider a windowing system.  A big window can contain smaller windows.
Each window can display itself.  A large window displays itself by displaying
its smaller windows.  It would have an array of subwindows, and would
iterate over them, performing the DISPLAY operation on each one.  However,
since different subwindows display different kinds of things, there must
be run-time binding.  In a conventional language this would be implemented
by case statements.  However, case statements result in code that is much 
less reusable, since adding a new kind of window requires adding a new case 
to a whole bunch of case statements.

You could implement an object-oriented Ada with a preprocessor by 
rewriting late-bound procedure calls into case statements.  In this case,
your preprocessor would be automatically maintaining the case statements.

Ralph Johnson