Re: List container straw man (NJR V4)

[Jeffrey Carter <jrcarter@acm.org>]

Nick Roberts wrote:
> 
> Okay, I've popped my own proposal on a web site:
> 
> http://www.adaos.ukf.net
> 
> with pointers to the rivals^H^H^H^H^H^Halternatives I'm aware of. Do please
> pay a visit.

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 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.

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.

Is_Empty and Length are basic list operations that are missing.

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

A concrete implementation should document the time complexity of every
operation, so the client can make appropriate choices of operations.
This argues against putting them in the private part. For an unbounded
list, the time complexity of the string- and dequeue-like operations
will be O(N), since they will have to do deep copies. The time
complexity of the indexed operations will be O(N), since they have to
count down the list. The cursor-based operations will tend to be O(1);
since they have the lowest time complexity they should be the preferred
operations and should therefore be presented first.

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.

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

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail