Re: ADT List

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

Hallo!

>    Not true. There is an alternative for simulating "well-behaved"
> constructors in Oberon-2 but it does come at a price: the same price as
> message passing as used for the GUI parts of the Oberon System.

I'm not sure if this gives us any advantages. Howver if we implement
such thing we should implement the more convential constructors, too.

> I used this approach quite successfully in my old "Nice Class Library"
> project which sadly got shelved. If I had the sources here I would gladly
> contribute them, but they sit on my Amiga back in Germany. :-(

Name the advantages.

>    However, I don't think that "Reverse" or "Filter" should even be part of
> the container class itself. They should rather be provided externally, most
> likely using some kind of "Iterator" or "Carrier-Rider" design pattern.

Yes, they are operators that act on iterators. They use other operators
(on iterators) to store the result.

>    My "Nice Class Library" (NCL from now on) project seperated Iterators
> into a class hierarchy on its own. Container classes exported a method

I strongly suggest to support iterators as much as possible an should
interals only for speed.

>    I would no export these. They should only be accessible through the
> iterator or rider or whatever the "accessor" is called (Enumeration in
> Java).

I would export them ;-) There should always be a generic interface
using iterators but direct access should be possible, too, for speed
resons. Howver, such member attributes should be marked as non-portable
btween different containers/implementations.

Btw.: Object should definitely have a Copy/Clone method. Or even a DeepCopy
and Copy method?

-- 
Gru...
       Tim.