Re: List Container Straw Man (NJR V5R1)

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

"John English" <je@brighton.ac.uk> wrote in message
news:3C0E1B51.253F5E98@brighton.ac.uk...
> Nick Roberts wrote:
> >
> > (3) instead of having numbered cursors inside the list object, it would
be
> > possible to provide a separate cursor type, objects of which would be
> > attached to a specific list object by an Open procedure (and detached by
a
> > Close).
>
> Why bother with Open and Close? Why not just operations like First(L)
> (which returns an iterator pointing to the first element of list L)
> to generate iterator/cursor values on demand? I'm not sure I see the
> point of what you're proposing...

If a list has two (or more) cursors pointing into it at the same time, and
then an item is deleted (by one cursor) which affects the other(s) (because
the item was adjacent to it/them), the internal status of the other
cursor(s) must be adjusted appropriately.

If cursors are separate objects, it is therefore necessary not only: (a) for
each cursor to have a means of access to the list into which it points, but
also (b) for every list object to have a means of access to each of the
cursors that point into it.

The mechanism for (b) that I envisaged was a linked list (ironically). Which
means that before a cursor can be used to point into a list, there must be a
way to insert it into this linked list (e.g. Open), and, for efficiency and
bug-catching, there needs to be a way to remove it from the linked list
(e.g. Close).

Ramification: the list and cursor objects would both have to be declared
aliased by the user (yuk).

These complications make me doubt, in fact, that having separate cursor
objects would be any advantage.

There is a secondary point to make here. I have used the term 'cursor',
distinct from 'iterator', because I intend cursors to be: list specific;
bidirectional; randomly addressable. I intend to provide a further facility,
called iterators, which will be: container-wide; monodirectional; strictly
sequential. This is my terminology, no-one else's; apologies in advance for
any confusion.

--
Best wishes,
Nick Roberts