From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3f2295ac59ed2cc0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-06 12:23:48 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!ppp-1-176.cvx1.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: List Container Straw Man (NJR V5R1) Date: Thu, 6 Dec 2001 17:36:35 -0000 Message-ID: <9uok4i$9pkpe$1@ID-25716.news.dfncis.de> References: <9u6ahm$6gdc1$1@ID-25716.news.dfncis.de> <3C0E1B51.253F5E98@brighton.ac.uk> NNTP-Posting-Host: ppp-1-176.cvx1.telinco.net (212.1.136.176) X-Trace: fu-berlin.de 1007670227 10277678 212.1.136.176 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:17529 Date: 2001-12-06T17:36:35+00:00 List-Id: "John English" 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