Re: List container strawman

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

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3BF2A186.F1911068@boeing.com...
>
> Yes, but I was referring to a comment that suggested an Assign procedure
> needs to be provided even though Element is private. In that case you
> might as well make Element limited private since it buys you additional
> applicability without changing how the component is instantiated.
>
I would agree that once you've gone to the effort of insisting there be an
Assign and an "=" in the generic formal part, then you might just as well
have made it limited private and enabled the creation of lists of just about
anything.

But I don't want to have to specify an Assign and an "=" every time I want
to stack up some integers or something similarly simple. I just want to get
the job done with as little effort or excess baggage as is possible.


> Of course, the real reason not to import Element as private is that it
> is an incorrect specification, and precise specification is essential to
> design by contract. A generic package has 2 specifications: the generic
> formal part, which should specify precisely what the client must provide
> to use the package, and the package specification, which should specify
> precisely what services the package provides to its clients.
>
Interesting, but IMHO, not compelling. Some folks may want a list package to
satisfy all sorts of requirements that are of some kind of academic
interest. They may even want a formal mathematical proof of correctness. I
don't think any of this Moves The Mission Forward. My big questions are
"Does it work reliably?" and "Is it easy to use?". Design by contract,
Ravenscar profiles, Mathematical proofs, etc. may all contribute something
to question #1, but if they start getting in the way of question #2, I'd
find that a hindrance to producing something large numbers of people will
want to use.

If we insist on Design By Contract or some other approaches as requirements,
I'd ask "Do all the other packages provided by the Ada standard meet these
requirements?" I'd suggest that they probably don't - in which case, why
should a data-structures-add-on to the language need to do so?


> A formal private type specifies that the package requires "=" for type,
> when in fact a list does not use "=" for its Element type.
>

I'd suggest that no matter how hard you try, you aren't going to get me to
shed a single tear over the fact that an "=" operation came along for the
ride even though a List package (according to what definition? mine is
pretty loose!) doesn't need it. Every time I write a math function for a
type Float, I bring in a whole slew of operations I may not need. Every time
I "with" a package, the same thing happens. Every time you have a generic
formal of "digits <>" or similar, you bring in operations that may not be
needed. I respectfully submit the question: "So What?" :-)

No matter what we do, we will *never* arrive at a "Perfect" List package.
The best we can hope for is a "Good Enough" List package that covers some
sufficient bulk of the possible uses and does so as easily and with as much
functionality as can reasonably be had.

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/