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

[Ian Rae <ianrae@istar.ca>]

> From: Tim Teulings <tim@edge.ping.de>
> To: ooc-list@informatik.uni-kl.de
> Subject: Re: ADT Lib (4.2) (is it 5 now?)
> Date: Thursday, June 11, 1998 3:41 PM
> 
> Hallo!

Welcome back. Short holiday!

> 
> > Writers have no other state than position.  After writing an
> 
> I think its the other way round. It is more likely that the most
> general writer export much less position information.

I think we're both saying the same thing: the most generic writers
have no position information.

My dilemma is "what does it mean to be a writer of a positionless
container like a bag?".  And as far as I can see, such a writer
is a stateless object.

But after reviewing AcRider.Mod I think that it's Rider object is a good
solution:
-it combines reader and writer functionality into a single 'rider' object.
 This neatly gets around the semantic problems with position:
 a rider is guarunteed to visit each element once.  No particular
 order is guarunteed (for generic riders; specialized riders may
 traverse in a predictable manner).
-it uses replacement semantics for writing. 
-postion can be set to any value between 0 and Size(). positioning
 to Size() places the rider at the NIL end marker.
-it avoids the class explosion problem MVA mentioned

> 
> > So I'm proposing Writers be dropped and Readers be renamed
> > to Enumerator or Iterator, in order to avoid confusing Oberonites.
> 
> No, don't do it.

No need to do it with AcRider as currently proposed.  Whew!

> <snip>
> You are confusing things. No one wants to make writers the only way to
> add elements to a container. There will be of course special methods
> for each ADT that handle adding and removing of elements. Write are
> only used as automatic tool for generic data transfer.

OK. Good.


Add/Remove methods for Container:
----------------------------------------------------
I'm not sure why these can't be included.  Even set ADTs have Add and
Remove operations.  Are there ADT's that don't?

The semantics would be:

PROCEDURE (c: Container) Add* (obj: AcObject.Object);
(* Ensures obj becomes a member of the container.
The size of the container may or may not change.
eg. for Sets this method will do nothing if obj is already in c.
ADTs that allow multiple copies of same object in the container
would always add obj to the container.
*)

PROCEDURE (c: Container) Remove* (obj: AcObject.Object);
(* Ensures that the membership count of obj in c is decremented
by one.  If obj was in c once, then it is removed.  If obj was in
c multiple times, then one copy of obj is removed (with no guaruntee
of which copy gets removed).  If obj is not in c then nothing is done.
*)


--Ian