Re: ADT Lib (4.2) (is it 5 now?)

[Ian Rae <ianrae@istar.ca>]

----------
> From: Eric W. Nikitin <enikitin@apk.net>
> Michael van Acken wrote:
> > I'm not sure what you mean with `Iterator'.  Myself, I see both
> > `Rider' and `Modifier' as something that is moved along by the user,
> > while an `Iterator' is something that is applied to a list (container,
> > whatever) as a whole, as an atomic action (from the callers point of
> > view).  Therefore I will quote again the relevant part of List.Mod
> > (they are list-centric, I know), and ask you to describe how your idea
> > of `Iterator' differs from mine:
> 
> I forgot about those (Apply(), Map(), and Select()).  (Sorry!)  I was
> thinking of Iterators as separate classes, just like Riders and
Modifiers,
> but I can't think of any particular advantage to doing it that way.
> 
> So, basically, my idea of iterators seems to match yours.

I'm starting to think the reader/writer approach won't
be suitable.  The problem is with positionless containers
like sets or bags. Readers make sense for both positionable and
positionless containers. The reader object has to maintain the 
state of the traversal.

Writers have no other state than position.  After writing an
object to a Bag, for instance, the only thing that's changed 
state is the Bag.  An object without a state probably doesn't 
need to exist.

So I'm proposing Writers be dropped and Readers be renamed
to Enumerator or Iterator, in order to avoid confusing Oberonites.

The functionality for modifying containers would be done as
methods of each container.  Add() for Set, Push() for Stack, 
and AddToFront(), AddToEnd(), and others for List, etc.
This approach also makes simple containers much easier to 
use -- no intermediate writer object needed.

2. Regarding Mike's pointers to Booch components:

They use generics (ie. templates in C++) that Oberon-2 lacks.
How to get around this?

3. May I suggest that the res variable in rider be "sticky" -- that is,
 once it sets to a non-done value, it holds that value and the 
 rider refuses to do any more work until r.ClearError is called.
 This greatly simplifies programming since res doesn't need to
 be checked after every operation.

--Ian