Re: Container reqs

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

Ted Dennison<dennison@telepath.com> writes:

> In article <3BD626BF.4CAEAF69@acm.org>, Jeffrey Carter says...
> >
> >Ted Dennison wrote:
> >> 
> >> It probably wouldn't prove too much of a hardship in Ada to limit the 
> >> component library to non-limited definite types.
> >
> >Most of the data structures in the PragmAda Reusable Components can 
> >handle any type the client can define an Assign procedure for. That 
> >includes many useful limited types, such as most of the data structures.
> 
> True. But when you take that approach you have to do one of two things:
> 
> 1) Force *every* user, including the >90% using only non-limited definite types,
> to create an "assign" procedure so that they can instantiate the container
> package. One of my personal no-no's of design is forcing extra work of this
> magnitude on every user to support an exceptional case.
> 
> 2) Create separate versions of the same component for use with
> limited/indefinite types. 

Correct.

Although another option, that I mention without really supporting, is
to use gnatprep to provide the two packages above, from a single
source. That eases the maintenance burden. But it won't be standard
Ada. 

> I see that you chose 1, and tried to mitigate the effort with
> another helper generic. But again, all this is complicating things
> significantly for the benifit of a small percentage of users.

How do you know it is a "small" percentage?

> Is there anyone out there who really thinks that being able to
> handle such types is a requirement, given that you can still handle
> pointers to them, and doing so would complicate the facility for
> everyone?

The packages in SAL were built precisely because I needed them in one
or another project I was working on. I don't know how many others
would use the full feature set, but I will in future projects. I use
limited indefinite types a lot!

Maybe this weekend I'll find time to sift thru my project code for
some real examples.

-- 
-- Stephe