Re: List Container Straw Man

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:u1yjacqea.fsf@gsfc.nasa.gov...
> Well, I find this very confusing; there is not enough documentation
> for me.
>
> First, you switched from "Sequence_Reproducer" to "Sequence_Recorder".
> Or maybe you left out a type?

I made a mistake: in the Print_a_List procedure declaration, I used the type
Sequence_Producer when I should have used Terminating_Producer. Sorry.

> Why are there three (or four) independent types?

Each adds one extra level of functionality. This is vitally important.

> How do I write to a
> producer object in the first place, so there is something to read?
> Conversely, how do I read from a recorder?

Remember, an abstract type promises certain operations (and assumed
characteristics). The concrete types derived from it must fulfil those
promised operations (and should fulfil the characteristics), but nothing
stops them adding more operations (and characteristics) of their own!

For example, a list type might be derived from Sequence_Recorder, so that
its contents can be read using Read and End_of_Data, and then re-read using
Restart, and then rewritten using Rewrite and Write. These are the promised
operations that the list type must fulfil, but it could add many others
(insertion, deletion, whatever).

Take another example, a random number generator (RNG). An RNG type might be
derived from Sequence_Producer (the most primitive, non-terminating type).
This means you can read from it using Read, but there is no end to the data
(and no End_of_Data function). 'Read' is the sole promised operation. The
RNG type would doubtless add at least one other operation to allow seeding
of itself.

This is why it is vital to have many types, each adding a small set of extra
'promised' operations.

And because objects (values) of both the list type, the RNG type (or indeed
any other container type conforming to the design) can be passed straight
into any unit which takes one of the abstract iterator types as a parameter,
it means you get the 'write once, use anywhere' effect of good software
engineering.

> > In this way, a piece of software which only needs to iterate over a
> > container can be passed any of the list types, or other container types.
>
> This is true. But it leads to the "complex instantiation" problem that
> is one requirement for the list package under discussion.

Please see my reply to Marin in this thread. I hope it shows that the
instantiations you need (two) are not really all that onerous.

> It also introduces tagged types, which some users might want to avoid
> (they can have run-time overhead, or be hard to test).

I don't think that's true in the great majority of cases. Ada can implement
tagged types very efficiently (because it does not have to deal with
multiple inheritance). I suppose hard data on this will be hard to get.

> Personally, I've never run across a situation where this abstract
> container design really made sense; it was always more important to
> optimize the implentation for real-time issues (I'm a rocket
> scientist, after all :).

I use this scheme all the time. I don't think it's unsuitable for most
real-time software. Many actual container types will be (but that's a
different matter).

> In a truly complete library, I think both options should be available;
> abstract containers and concrete, simple lists. Perhaps the "Dennison
> List" package could be used to implement the doubly-linked list
> variant of the abstract container package; would that work for you?

For the sake of saving one instantiation? Maybe, but I doubt it.

> > Please don't get this elementary aspect of the design wrong!
>
> "Wrong" is too strong. Just because some people give different design
> options different importance does not make them wrong!

You're right, of course, but I get a little frustrated at times, Stephe!

--
Best wishes,
Nick Roberts