Re: ADT Lib (5)

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

Hallo!

[I'm back :-)]

> We could do a hierarchy like this:
> 
> Rider +---- Reader +---- ReaderForward  +---- ReaderForwardModifier
>       |            +---- ReaderBidirect +---- ReaderBidirectModifier
>       |            +---- ReaderIndexed  +---- ReaderIndexedModifier
>       +---- Writer +---- WriterForward  +---- WriterForwardModifier
>                    +---- WriterBidirect +---- WriterBidirectModifier
>                    +---- WriterIndexed  +---- WriterIndexedModifier
> 
> We get 2*3*2 concrete classes, with the ugly property that the
> `Modifier' classes have no common direct ancestor, likewise `Forward',
> `Bidirect`, nor `Indexed'.

I'll will look at the C++ iterator hierachie before giving a definite
statement about that. I'm sure STL comes without using multiple
inheritence. Also I'm not sure if the same hierachie with the same
feature set must aply to both readers and writers.

> Additionally, this layout violates several of the OOP design rules I
> quoted above.  Therefore I prefer to integrate the access method and
> positioning into the basic rider, and create only one sub class
> `Modifier' (to use Eric's term).

> So my all new rider proposal from `AcContainer.Mod' looks like this:

> --begin quote AcContainer.Mod-- 
> --end quote AcContainer.Mod--

With this aproach you solve the interface problem but you will get the
problem that now and everywhere all algorithms will have to add
runtimechecks on the features of a iterator.

> Is there a general way to move data from one ADT instance to a
> instance of a another ADT?  As a side note, now `Container' does not
> even provide the methods `Add' and `Remove' anymore (see below).

Possibly not via mameber functions of a baseclass but via a set of
restricted iterators.

> I believe, this point of view incompatible with the language Oberon-2
> (single inheritance, no interface class).  If you have a valid
> alternative to the 2*3*2 class hierachy from above, please speak out.

I'ltt will take a look at C++ (that will be monday) before offering a
alterantive.

> This would be a severe case of bad design.  `Reset' is a rider method,
> not a method of the container.  Therefore it conflicts with this rule:

No, reset is not a rider method because reset is not a *feature* of the
rider baseclass. If the rider base class (sequential iterator) does not
now about backstepping or random indexing it also does not know about
indexing with is similar to moving backwards several times or random
indexing with index 0. Only the container knows how to handle its own
iterators so it does belong to the container.

> Without a `Container', I have nothing to attach the `Rider' to.

As told before there is a *very* loose connection between rider and
contaiber. Is see no need for your 'attachment' between container and
rider at least nothing that must be reflected by the interface. The
iterator may have a pointer to its container but this is a private
thing between the special implementation of the container and its
iterator. Since the container always creates its own iterator they can
handle that during initialisation phase.

> First: "AcContainer" is abstract.  It does not provide any
> implementations whatsoever.  Where would you introduce the data type
> rider, if not for `Container'?

See above.

> Second: If an ADT is not a container, then it is not derived from
> "AcContainer".  It is as simple as that.

That of course is true.

-- 
Gru...
       Tim.