Re: why not "standardize" the Booch Components? (was Re: is Ada dying?)

[Jeffrey Carter <jeffrey.carter@boeing.com>]

Pat Rogers wrote:
> 
> Many of us have developed libraries of reusable components over the years.
> It is a great way to learn a language.  We all have things we like about
> them.  Some are extensive and well done.  However, we would all clearly
> benefit by agreeing to make one of them the de facto standard.  (Formal
> standardization is desirable too, IMHO.)
> 
> I propose the Booch Components be that standard.  If there is a better suite
> I haven't seen it and I've seen many of them.  However, there may very well
> be a better collection of components.  Let's discuss them.

I have serious reservations about the BCs. They are based on theory
rather than practical use. Booch developed his taxonomy which determines
what components exist. Does the developer really need to choose from 21
(or whatever the number is now) different queues? In my experience, the
answer is no. Both bounded and unbounded variants are needed, with both
protected and unprotected variants of each (the unprotected variants are
primarily for creating structures of structures, which the BCs did not
permit the last time I looked at them). Within the protected forms, a
blocking variant is needed. That gives 6 variants of queues, which my
experience shows are useful over 90% of the time. They also provide the
building blocks if you really need a lesser used variant.

A similar thing arises from the partitioning of operations into
modifiers and selectors. Everyone is used to pushing things onto a stack
and popping things off. But popping something off a stack involves both
modifying the stack and selecting a value from the stack. Theory says
this is a No-No, so we'll separate them into Pop, the modifier, and Top,
the selector. Of course, in practical use, every call to Top is
immediately followed by a call to Pop, indicating that the real
operation on the abstraction combines these 2 theoretical operations.

The GRACE components from EVB also distinguished between constructors
and modifiers. This resulted in what should have been simple code such
as

loop
   exit when End Of File;

   Read Item from File;
   Append Item to List;
end loop;

turning into

loop
   exit when End Of File;

   Read Item from File;

   if List is Empty then
      Construct List from Item;
   else
      Append Item to List;
   end if;
end loop;

unnecessarily complicating what should be simple code (of course, in
this small example it doesn't look too bad).

Thus, I suggest using components derived from practical considerations
rather than theoretical ones. Ten pragmatic Ada points to those who can
guess which ones I prefer.

-- 
Jeffrey Carter