From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7ee10ec601726fbf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-11 10:52:19 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newspeer.radix.net!uunet!ash.uu.net!xyzzy!nntp From: Jeffrey Carter Subject: Re: why not "standardize" the Booch Components? (was Re: is Ada dying?) X-Nntp-Posting-Host: e246420.msc.az.boeing.com Content-Type: text/plain; charset=us-ascii Message-ID: <3BC5D730.DA950CC7@boeing.com> Sender: nntp@news.boeing.com (Boeing NNTP News Access) Content-Transfer-Encoding: 7bit Organization: The Boeing Company X-Accept-Language: en References: <3BC30674.BA88AAB6@brighton.ac.uk> <9pvv3t$ves$1@news.huji.ac.il> Mime-Version: 1.0 Date: Thu, 11 Oct 2001 17:30:24 GMT X-Mailer: Mozilla 4.73 [en]C-CCK-MCD Boeing Kit (WinNT; U) Xref: archiver1.google.com comp.lang.ada:14303 Date: 2001-10-11T17:30:24+00:00 List-Id: 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