Re: Container reqs

[Jeffrey Carter <jrcarter@acm.org>]

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