Re: Ongoing discussions

Anthony Christian Langsworth (aclangsw@nospam.socs.uts.EDU.AU)
Thu, 3 Nov 1994 10:57:57 +1100

On Mon, 31 Oct 1994, Duncan Handley wrote:

> In regards to LLIST,
>
> 1. Why don't you correctly hide the features, especially attributes, from
> other classes

When I rewrote linked list last semester, the aim was to have a working
version out quickly. The changes that Daniel Mahler and others
have suggested regarding export policies will be implemented soon.

> 2. Try to make a feature that adds a item to the start of the LLIST

Originally I assumed one would use mark, then add_left then return.
However, that leads to some problems. Will also think about implementing.
For those reading this message apart from Duncan, "put" adds an element
at the end of the list.

> 3. Add preconditions to both add_right and add_left so that they can't be
> used at the start or end of the list, or add if statements to handle
> these cases - (this would be preferable, it would be more robust)

Agreed. See Mike Riley for details of new code and assertions.

> I'm, sorry about all the discussion that was created re. this class.
> When i first got hold of it, i thought it was a proper library class, not
> a student's weekend project. In future, if you are going to give your
> library classes to the public domain, could you try and ensure they are
> fairly bug free and robust next time.

I say again that the class was only meant to be a bug fix for certain
features in time so last semester's PP students would have a list that
they could use. I agree that the list isn't as robust as it could be but
I didn't have that much time free last semester.

And I like to point out that this was no "weekend project" given to me by
Rob Rist or anybody else. I did it out of my own choice because the bugs
in it were causing a lot of problems. You think that this LLIST.E is
bad, you should have seen the last one ....

The previous two paragraphs are not a flame against Duncan but I do
want people to realise that it was never meant to be superefficient
nor was it my intention to fix all the bugs in the LLIST features that
no one doing PP was ever going to use.

The new LLIST.E may have caused more sophisticated users hassles but I
would recommend you using the library list class anyway. It follows a more
RISC-like concept with its functions, is smaller and allows multiple
cursors (called iterators). Note that the make procedure of the Eiffel/S
library LIST class requries a boolean as an argument. If this is true, it
will NOT allow multiple copies of the same element to be inserted into the
list. ( grab a short listing for more details )

Anthony Langsworth
Email: aclangsw@nospam.socs.uts.edu.au
anthony@nospam.ftoomsh.socs.uts.edu.au
CompuServe: 100033,3320