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,ac39a12d5faf5b14 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-25 19:42:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!demon!diablo.netcom.net.uk!netcom.net.uk!psiuk-p2!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: Grace and Maps (was Re: Development process in the Ada community) Date: Thu, 25 Apr 2002 10:06:07 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3CB46975.90408@snafu.de> <3CBAFFEE.2080708@snafu.de> <4519e058.0204171036.6f0a7394@posting.google.com> <3CBDD795.4060706@snafu.de> <4519e058.0204180800.44fac012@posting.google.com> <3CBF0341.8020406@mail.com> <4519e058.0204190529.559a47ae@posting.google.com> <5e9b8c34.0204241829.67633bdf@posting.google.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1019743571 20786 136.170.200.133 (25 Apr 2002 14:06:11 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 25 Apr 2002 14:06:11 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:23131 Date: 2002-04-25T14:06:11+00:00 List-Id: "Brian Gaffney" wrote in message news:5e9b8c34.0204241829.67633bdf@posting.google.com... > > If I get your intent, I don't think this would work since Grace.List > would be generic. (Which would be a pain if you needed Bounded > because you didn't wish to instantiate an Unbounded.) > O.K. So maybe we just need Grace.Lists and Grace.Bounded_Lists? Probably, 90% of the uses will just want a dynamically allocated, linked list implementation as being Good Enough(tm). Hence, it can benefit from the shorter name. Lesser demand packages can have longer names either by dotted-child notation or just more detailed names. Or we could just invent new names to describe data structures with different characteristics as I suggested somewhat less seriously elsewhere. You could have Grace.Lists, Grace.BLists, Grace.Whatever.... So long as it is documented what the characteristics of a BList are, we don't have a problem. Or completely make up new names that don't play to anyone's preconceived notions of what they are.Grace.Rosters? Grace.Rolls? Grace.Catalogs? There you've got three more names to describe lists with different caracteristics. > > I like the Grace.Containers.Lists idea. Perhaps the children could be > something like Grace.Containers.Bounded.Lists? Then you could have a > Grace.Containers.Maps and Grace.Containers.Bounded.Maps, etc. I don't > know how well this would extend to other types of containers. > We've got to be *real* careful not to make a naming scheme that tries to have so many branches to such a depth that everyone will later decide that it is a Royal Pain In The Posterior to use it. If we start creating subtrees to describe implementation strategies and characteristics, where does it end? Grace.Containers.Bounded.Task_Safe.Realtime.Deterministic.Maps? :-) We can't solve *all* the problems today. A Grace.Containers.Lists and Grace.Containers.Maps is probably sufficient granularity for now and a sub-branch could be created later if there is any real need. (Some flavor of Grace.Bounded_Containers? Although I'd favor shorter names for these things. Like Grace.Boxes or Grace.Jars - or even an acronym.) > Another way to get a default (assuming anyone could stand it) would be > to provide the different version (unbounded, bounded, etc.) and uses a > renames to define the 'default' type (i.e. generic package > Grace.Containers.Lists renames Grace.Containers.Unbounded.Lists). Apply the K.I.S.S. principle here. One of the design criteria was that it be relatively easy to explain to students - and that was one of the reasons people had objections to the Booch Components. Too many layers and too much complexity for the average beginner to make good use of it. Providing a default renaming of some alternate implementations might not be a bad way to go, but I'm wondering if it would create too much confusion? Would it be easy to explain to a beginner? I think that so long as the tree structure is extensible without too much pain, it will be satisfactory. One day, we might want a bunch of packages with the power of the Booch Components & I could see building it under a heading Grace.Rich_Containers (or whatever) but we need to continue to have something reasonably simple and straightforward to handle a large percentage of the needs without too much pain. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com