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,88093378be1184d4 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-07 13:09:27 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.ems.psu.edu!news.cis.ohio-state.edu!news.maxwell.syr.edu!lon1-news.nildram.net!newsfeed.freenet.de!news-x2.support.nl!news-x.support.nl!psinet-eu-nl!psiuk-p4!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: List Container Straw Man Date: Wed, 7 Nov 2001 15:30:30 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9sc5l8$9b7$1@nh.pace.co.uk> References: <9s941p$11mrei$4@ID-25716.news.dfncis.de> <9s99tt$pdb$1@nh.pace.co.uk> <9s9s8p$11vt7l$1@ID-25716.news.dfncis.de> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1005165032 9575 136.170.200.133 (7 Nov 2001 20:30:32 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 7 Nov 2001 20:30:32 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:16015 Date: 2001-11-07T20:30:32+00:00 List-Id: I don't mind underlying complexity if there is any way to hide it. If the design can be such that you have the complex versions around but through instantiations or inheritance you can get a simpler version, then great. (Not sure how you would do that...) The important thing in my mind is that there are going to be a bunch of potential users who just need to slap something simple together to hold a bunch of data and they're not going to want every conceivable option available to them to do that. I could imagine a design of a component library that would include some kind of plain vanilla Lists and Maps that let you do the simple things and then extend it with variants that allow more complex things to occur, such as inheriting from iterators or controlling storage or whatever. Get something that covers 80% of the average usage first, then worry about the more arcane cases later. I don't think that a first cut at a standard component library should attempt to be the software equivalent of a Swiss Army Knife, covering every conceivable usage. Just your basic Boy Scout Knife with two or three blades. Can you imagine a way to take the classes that Nick suggests and use them as the basis on which a simple list similar to what Ted suggests is built? That means you have the underlying power if you want to peel away the layers and use it, but for the simple cases you've got a nice, simple, instantiation with nice simple subprogram calls? This might be a way to utilize the BC's. If Ted, et alia, could be clever enough to hide the complexity under some other layer, they might be able to overcome the objections and get what they want. Hmmmmmm.......... 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/ "Stephen Leake" wrote in message news:u1yjacqea.fsf@gsfc.nasa.gov... > > In a truly complete library, I think both options should be available; > abstract containers and concrete, simple lists. Perhaps the "Dennison > List" package could be used to implement the doubly-linked list > variant of the abstract container package; would that work for you? >