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

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

Its a good point that possibly the Booch Components are "overkill". I
understand this in many respects. I've always wondered about the necessity
of having stacks and queues at all. A reasonable implementation of a
bi-directional list pretty much covers all those bases and in practical use
will handle 99.44% of everything you need in the way of linked data
structures.

The MFC has two data structures that get used with much regularity. Lists
and Maps. (O.K. I guess we could debate just what constitutes a data
structure and then debate what parts of the MFC might qualify, but I'd
rather not.) If there were similar Ada structures, I'd imagine this would
cover most of the things that show up in practical use. You'd probably want
versions that were task-safe and those that were not. Throw on top static vs
dynamic allocation and you've got 8 variants of data structures. Would that
be enough to handle most *practical* programming problems? IMHO, probably.

However, there is something to be said for adopting the Booch Components
as-is. A) Its already in existence. B) It has a recognizable name and
heritage. C) It has a textbook available that helps explain it. D) Even an
imperfect standard is better than (d1) no standard at all and/or (d2) an
endless debate about which of many existing or possible container libraries
should be adopted.

If the BCs supply - or can be made to supply - Lists & Maps in
static/dynamic and task-safe/monoprogrammed variants, then maybe its worth
adopting. All the rest can be viewed as interesting intellectual exercises
that may or may not find much practical use, but are along for the ride
anyway. There's no technical penalty for not using what you don't need,
right?

I'd like to hear from one or more compiler vendors concerning what
requirements they would have for any component library that they'd be
willing to distribute with their product.  If there isn't a single vendor
willing to distribute *anything* as a candidate for an Ada Standard
Component Library, then this is all a profound, if not sinful, waste of
time.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3BC5D730.DA950CC7@boeing.com...
>
> 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