Re: List container strawman

["Ehud Lamm" <mslamm@mscc.huji.ac.il>]

Thanks fro the effort. Sorry I didn't have time these past week to
contribute anything.

A few questions/comments. I am not sure about many of these.

1. In my scheme "Element" is a generic parameter of the top package
(Containers), and not of the specific implementations.
(Remember, my attemp for having interface inheritance)

2. Why is List private? Shouldn't it be limited private, so we avoid
possible erros caused by aliasing?
We may need a private implementation, but I'd prefer this not to be the
default, since it can come and bite you when you don't know what you are
doing. The private version is for library builders and more advanced users,
best used as part of a layered design that hides the list itself.
(If the majority wants private, at least the spec should mention the
possbile problems)


3. "Construct" is indeed a long name. We can, as part of the library, decide
on some standard name for this like - or +

4. I've seen many implemenations that paremtrize Insert and Remove with a
direction parameter, instead of having seperate routines (_Back/_Front). I
am not sure I know which approach I prefer...

5. Front() and Back() raise execption on Empty List?


6. I like having a "No_More_Elements()" operation as part of the Iterator
interface. It saves time compared to Size (for containers that don't keep
count of size), and I don't like programming with exceptions ("exceptions
for control flow").

7. Sort should be in a child unit.

Finally, a more general question:
Is this a DeQueue or a Doubly-linked list? Should these be two different
abstractions? (IMO: Yes, they should).

Ehud