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,842accb6a7d76669 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-04 15:43:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!sjcppf01.usenetserver.com!usenetserver.com!news-west.rr.com!news-east.rr.com!wn2feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc05-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3BE5D2A4.5432024E@worldnet.att.net> From: James Rogers X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: List container strawman 1.1 References: <3BE301D1.4010106@telepath.com> <3BE31DD5.FF96AFE0@san.rr.com> <3BE43E6D.109111F4@acm.org> <3BE591CB.72F76462@san.rr.com> <3BE5BF56.582AD0AB@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 04 Nov 2001 23:43:23 GMT NNTP-Posting-Host: 12.86.36.121 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1004917403 12.86.36.121 (Sun, 04 Nov 2001 23:43:23 GMT) NNTP-Posting-Date: Sun, 04 Nov 2001 23:43:23 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:15777 Date: 2001-11-04T23:43:23+00:00 List-Id: Jeffrey Carter wrote: > > Yes, the Position includes information that identifies the list, and > operations make sure it matches the list supplied. If they don't match, > the client has made an error and is notified via an exception. It is > never possible to supply the right list and the wrong position, or the > wrong list and the right position, and have an operation succeed. > > Note that positions are not iterators. They do not iterate. Client code > may use them for iteration, but that does not make them iterators. > Think carefully about the implications of iterators with controlled types. How many iterators will be allowed for each list instance? When the list is finalized, how will you finalize all the iterators accessing the list? Does this require the list accesses to be implemented using a reference counting mechanism? The rules you state above for iterators are good as they stand. You do not state whether or not you can have multiple iterators per list instance. If you can, then you have an interesting complexity when dealing with insertions and deletions to/from the list. For instance, what happens when you delete an element through one iterator that is being accessed through another iterator? Is the iterator generated using a Singleton pattern? This will allow multiple iterator "instances" to be created, but they would always share exactly the same state. Accessing such iterators in a tasking environment would require the iterator to be a protected object. Jim Rogers Colorado Springs, Colorado USA