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 23:49:04 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Message-ID: <3BCA86C7.BB252751@acm.org> From: Jeffrey Carter X-Mailer: Mozilla 4.7 [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: Mon, 15 Oct 2001 06:49:03 GMT NNTP-Posting-Host: 206.133.138.102 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1003128543 206.133.138.102 (Sun, 14 Oct 2001 23:49:03 PDT) NNTP-Posting-Date: Sun, 14 Oct 2001 23:49:03 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Sun, 14 Oct 2001 23:45:24 PDT (newsmaster1.prod.itd.earthlink.net) Xref: archiver1.google.com comp.lang.ada:14500 Date: 2001-10-15T06:49:03+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. Can we in general agree on these? The following are PragmAda Software Engineering's views on these suggestions: > > (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 OK > > * 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] Not sure either way. Components are building blocks for problem level abstractions. A list is sometimes appropriate; other times a queue may be better. A developer should not have to dig around in the implementation of various sequential-access containers to find one that provides the required building block. > > * 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) Agree. The type should be Element so Item may be used as a parameter name. > > * The library should offer Algortihms (in STL-speak): sorting, searching > etc. OK > > * Standard iteration schemes over the various containers (I want both active > and passive versions) Agreed. However, we see no advantage to having active iterators (if the term has the same meaning to both of us). They merely require the developer to duplicate code that is in the passive iterator. > > * 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. Easy instantiation is appropriate for industrial-strength use as well. However, ease of instantiation should not take precedence over widespread utility. For example, it should be possible to create structures of structures. > > * Memory handling is important, but we don't want to have to do > library-level instantaions beacuse of Controlled types. Disagree. For industrial-strength use the precision of memory control using controlled types outweighs the inconvenience of requiring library-level instantiations. It will be interesting to see if general agreement can be reached, given the range of strong opinions on the subject. It may be as difficult as agreeing on a programming style. While I do not agree completely with the current Ada standard library, I would rather have it than no standard library. I think it was designed by a fairly small team; if it had required general agreement from the community I doubt if it would exist. -- Jeffrey Carter PragmAda Software Engineering