Re: ADT Lib (3)

[Tim Teulings <tim@edge.ping.de>]

Hallo!

> 1. I like the general approach that is trying to find a balance between
> power
>  and convenience.  NodeDesc having next and prev pointers seems worthwhile
>  because its highly convenient.

I think, we all agree about that. However there should be a more
general interface using Riders/Iterators. But i think we agree on the
principle use of Rider, too.

> 3. Riders need to traverse the list in a known order -- the order of the
> items in
>  the list!  MVA's suggestion that 

However special ADTs could offer various iterators with the same
interface but with different semantics. What about a back-iterator for
a list? You could invert a list simply by iterating over it using a
back-iterator iterating from the end to the begining, inserting every
value into a new list.

> MVA>In particular, no assumptions are made over the particular order in
> MVA>which data elements are visited.  The only guarantee is this: as long

> seems to make sense only for unordered data types like sets.

I think, we should define that an iterator per se does not define a
special order. We only specify that a iterator visits all vavlues and
that each value is only visited once. Derived class however can make
use of the internal representation of data and thus can give a special
semantic to the order. As told before they can even offer iteraotrs
with different semantics.

> 4. Riders should have a Reset function that moves them back to the
> beginning
>  of the list.  Much more convenient and efficient than having to create a
> new
>  rider if you need to traverse a list several times.

I think, it better that the ADT has a method for reinitializing a
iterator instead of allocating a new one. This way a iteraotr may not
be forced to store additional information (A list iteraotr does only
need a pointer to the current node. For reinitialisation it needs a
pointer to the list, too).

> 5. Some solution needs to be found for destructive traversal of lists using
> Riders.
> Often one needs to do something like

>   Probably this should be done by a sub-type so as not to
>   burden the ordinary Rider which only supports non-destructive traversal.
> 
>   Perhaps NewRider should be follow a factory pattern that creates a
>   variety of rider types based on its arguments.  Then the user could
>   specify a fast rider or a 'safe' rider (for non-destructive traversal).

By differentiating between readers and writers one can do this.

-- 
Gru...
       Tim.