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,8eff44ec1bcf8433 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-14 15:52:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!wn4feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc06-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3BCA173D.FA305845@worldnet.att.net> From: James Rogers X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Container reqs References: <9qctpn$lil$1@news.huji.ac.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 14 Oct 2001 22:52:25 GMT NNTP-Posting-Host: 12.86.32.203 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc06-news.ops.worldnet.att.net 1003099945 12.86.32.203 (Sun, 14 Oct 2001 22:52:25 GMT) NNTP-Posting-Date: Sun, 14 Oct 2001 22:52:25 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:14494 Date: 2001-10-14T22:52:25+00:00 List-Id: Ehud Lamm wrote: > > Let's try to make a list of req the Ada community in general can agree on, > and than see which of the existing libraries is closest and concentrate on > that. > > (the following are some suggestions) > > * It seems there is a general agreement to distinguish bouned from > unbounded versions. This can be attributed to a more general > (non-functional) req: the library should be applicable for RT Bounded and unbounded distinctions are useful. Do we also want to specify that bounded versions are allocated on the stack while unbounded versions are dynamically allocated from some storage pool? I believe this is what Dr. Lamm is suggesting. If so, I agree. For the unbounded containers we may want versions allowing one to designate the storage pool used. > > * I want a library organised around ADT properties (like "sequential > access", "set interface" etc) and not around implementations (doubly linked > lists). > [I think we should think of the best Ada apporach for connecting interfaces > and implementations. I explored many of the possibilities, like signature > packages, class-wide operations etc., and I am still looking for the best > method] This corresponds roughly with the approach taken by Java. It has containers that implement various kinds of lists and sets. They are organized by ADT properties and not by implementation details. As far as an Ada approach for connecting interfaces, my first impulse would be to define a set of abstract types for each category (i.e. sets and lists), then inherit from those types to create the concrete and generic container classes. > * From my experiens the item type is best accepted as a generic paramter (I > say this, before anyone suggests and "Object" type, and we start fighting > over MI) > > * The library should offer Algortihms (in STL-speak): sorting, searching > etc. Again, this could be done using abstract types and generic parameters, allowing a person to define the sorting, searching, etc. algorithm for a particular instantiation of the container. > * Standard iteration schemes over the various containers (I want both active > and passive versions) > > * Since I am thinking about using the library in education, I'd prefer to > make isntantaion as easy as possible (possibly, by supplying > pre-instantiated versiosn). I also prefer to hide the tagged nature of > interface relationships from casual and first time users. > > * Memory handling is important, but we don't want to have to do > library-level instantaions beacuse of Controlled types. Memory handling could be made somewhat transparent with the careful use of storage pools. Jim Rogers Colorado Springs, Colorado USA