Re: Container reqs

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

I'd rather see a plain-vanilla initial case that let me make lists of
Integers, Floats, Strings and Records (no tags, no discriminants, no
pointers, no nothing but plain vanilla records). That would probably handle
75% of the things that I would normally do.

From there, a variant of the same packages could be created that dealt with
limited private or other unusual generic parameter requirements. (Like
requiring "<" and "=" operators for sorting limited private stuff...) The
other variants can provide a nearly identical package spec, just offer
different advantages. Document the reasons for different variants so that
the user can choose the best variant for the job at hand and you've got
something there. (Why do we have Ada.Strings.Fixed, Ada.Strings.Bounded,
Ada.Strings.Unbounded otherwise? I'm lobbying to get the equivalent of
Ada.Strings.Fixed accepted and we can worry about the rest later.)

Give me the plain vanilla case and leave a branch open for more
sophisticated cases and I'll have infinitely more standard components than I
have right now.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:lKzB7.41007$ev2.48168@www.newsranger.com...
>
> 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.
>
>
> 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.
>
> 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?
>