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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no 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 11:58:54 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!193.190.198.17!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: why not "standardize" the Booch Components? (was Re: is Ada dying?) Date: Thu, 11 Oct 2001 14:44:22 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9q4pa7$1ad$1@nh.pace.co.uk> References: <3BC30674.BA88AAB6@brighton.ac.uk> <9pvv3t$ves$1@news.huji.ac.il> <3BC5D730.DA950CC7@boeing.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1002825863 1357 136.170.200.133 (11 Oct 2001 18:44:23 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 11 Oct 2001 18:44:23 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:14315 Date: 2001-10-11T18:44:23+00:00 List-Id: 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" 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