Re: List container straw man (NJR V4)

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

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3BF6CCD6.F7195928@acm.org...
> ...
> This is difficult to understand. This is the only place I've ever seen
> the concept of "cursorage"; it is certainly not a standard list concept.
> Combining the indexed operations and the cursor-based operations is
> called control coupling and makes the operations difficult to
> understand.

The word 'cursorage' is my own Carrollean invention. Feel free to improve
upon it.

As for the combination of offset and cursor-basing, I shall undo this
combination, to produce separate sets of subprograms (as, in fact, I had
before).

> The use of undefined types is confusing. I suppose they're declared in
> the parent package, but since we can't see the parent package it's still
> confusing.

[Smacks forehead] Sorry! I'll put the base package into the picture.

> The use of an abstract type and operations followed by a non-abstract
> extension and non-abstract operations doubles the size of the
> specification without adding any value that I can see. Every concrete
> list is going to have to declare and implement every operation, so
> declaring them abstract an additional time seems like a waste of time.

There are good reasons for having an abstract base. Avoiding extra code is
not a good reason for getting rid of it.

However, your comments have prompted me to re-evaluate putting the concrete
in with the abstract. I think I must remove it (to childerhood). The idea
was to avoid a further instantiation (since a child package must be
generic), but imposing a concrete type on any would-be list (derived from
Abstract_List) is too mauch baggage. Shame: we're back to two
instantiations; it seems hard to get away from them!

> Is_Empty and Length are basic list operations that are missing.

Oops! In they go. (Got lost in the rush.)

> A component should not raise predefined exceptions such as
> Constraint_Error. Use meaningful exceptions such as Cursor_Is_Null.

For some conditions, yes. Will do.

> A concrete implementation should document the time complexity of every
> operation, so the client can make appropriate choices of operations.
> ...
> Each operation should document its pre- and post-conditions, where
> applicable. Each operation should document what exceptions it may raise
> and under what circumstances; since exceptions are generally indications
> that the client has violated a precondition, the documentation for
> preconditions is usually a good place to document exceptions.

Okay. I said the documentation was brief! I'll add this stuff ASAP.

> With some more work this could be an acceptable standard specification.

Cool!

--
Best wishes,
Nick Roberts