Re: Container reqs

[James Rogers <jimmaureenrogers@worldnet.att.net>]

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