Re: ADT Lib (6)

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

Hallo!

> not agree with this definition, but I haven't seen any other proposal
> (disregarding Tim's hazy prose).  Until some other practicable
> proposal is made, the current AcRider module stands as it is.

Come on, it was not only some prose but also some hard fact and
arguments. What is still missing is an concrete interface proposal. I
will offer this. But before I make asugestion I want to look at the STL
of C++ to see how they implement it. Problem is, that I only have acees
to it and to its documentation at work and as we all now I am currently
on holiday. I will make the proposal at the start at the next week.

> With such semantics, I can add these methods to container again.  The
> question is: Is it worthwhile to have methods with such vague
> semantics?  Does anyone second this?

We cannot be sure, if this methods fit the need of all datatypes. I
sugest to way and see how we get along with the reader/writer stuff. I
we can implment writers the way I suggested it, we better should drop
the methods else they are definitely necessary.

> Another question: With the above specification, is it guaranteed that
> the statement sequence
>   c.Add(foo); c. Remove(foo);
> is a "no operation", i.e., will not change the state of `c' or the
> system?

I may. I you add an object that is already part of a
every-object-only-once ADT add will do nothing but remove will remove
the first ocurence, too.

> Instead of "obj.Hash()" or "o1.LessThan(o2)" I prefer proper
> functions, like "Hash(obj)" or "LessThan(o1, o2)".  The functions can
> be implemented as a procedure variable, or as a type-bound procedure
> of some base class.  See also Tim's posting about a "Compare" class
> some time back: http://www.uni-kl.de/OOC/ooc-list/msg00528.html

However we must find a semantic for changing such functions on the fly.
I propose that changing such functions on the fly is only allowed when
the ADT is empty. Implemented ADT can allow changing anytime.

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

One can work around templates by using special baseclasses. The
semantics of the ADTs change slightly (templates make genric ADTs type
save. A list<Bla> can only store objects of type Bla, our ADTs do not
have such implied type safty) but the changes are not principle better
or worse just different.

> Don't forget multi inheritance.

We cannot really work around this. This might e.g. a problem with my
reader/writer proposal. We will see.

> We will agree, that rider.Reset() is equivalent to r.SetPos(0)
> (assuming an indexed rider for the moment).  And you will also agree

That is the key problem. For a index rider this is ok, but not for
others since SetPos is not implemented for them.

> that `SetPos' is undisputable a rider operation.  It has to be a
> rider
> operation, because only riders have any sense of `position'; the
> container does not now anything about positions.

The container knows about its iterators. Also note that we are talking
about the special position first (or last) which is known to the ADT.

> We have two identic operations.  How can they differ in their
> receiver
> type?  You should rethink your argumentation, and maybe take a look
> at
> the "Common Mistakes" chapter of "OOC in O2".

I was argumenting that reset is not a reposition since not all
iterators can be repositioned via index (sequential and bidirectonal
cannot, while indexing can) thus is is a semantical error to
implement reset within the rider. Instead one must think of reseting as
reuse this iterator (don't allocate a new one) and reinitialize it.

-- 
Gru...
       Tim.