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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.254.74 with SMTP id ag10mr28162029pad.24.1447613660825; Sun, 15 Nov 2015 10:54:20 -0800 (PST) X-Received: by 10.182.87.132 with SMTP id ay4mr102156obb.14.1447613660777; Sun, 15 Nov 2015 10:54:20 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!i2no3633426igv.0!news-out.google.com!f6ni3478igq.0!nntp.google.com!i2no3154699igv.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 15 Nov 2015 10:54:20 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=68.145.219.148; posting-account=lzqe5AoAAADHhp_gregSufVhvwu22fBS NNTP-Posting-Host: 68.145.219.148 References: <1dolqizyi8gxi.t3173bhifuu1.dlg@40tude.net> <1705bpj6jrld0.1lc44o5yo6bj7$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <71896d8e-d147-4ad3-a612-5c865a10a59f@googlegroups.com> Subject: Re: A few questions From: Brad Moore Injection-Date: Sun, 15 Nov 2015 18:54:20 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:28369 Date: 2015-11-15T10:54:20-08:00 List-Id: On Saturday, November 14, 2015 at 5:37:32 AM UTC-7, Simon Wright wrote: > "Randy Brukardt" writes: >=20 > > You'd probably keep some state in the iterator object (some access to > > the file, at a minimum, possibly a buffer). The "cursor" would be the > > character. Each call to Next would put the following character into > > the "cursor". Easy-peasy. :-) >=20 > It's a pity that Next takes the iterator object as an 'in' > parameter. This means that, in general, the cursor needs to hold the > state. It certainly needs some way of indicating end-of-iteration; > perhaps a sentinel value. I found this to be a problem also. I have been working on an AI to potentia= lly add iterators to Ada.Directories and Ada.Environment_Variables for cons= ideration for Ada 202x (Ada 2019?). I was able to get a working implementat= ion using both an Iterator approach, and an Iterable container approach. So= far the Iterable container approach seems like a better choice here becaus= e it lets the programmer choose between either "in" or "of" syntax for the = loops. With the Iterator approach, you can only use "in" loops, although that's re= ally not a big deal, in my opinion. For both of these approaches, I found I also needed "in out" parameters for= these interfaces. In fact, looking at my iterable container implementation= it appears that First, Next, and Iterate all need to have 'in out' paramet= ers. For Ada.Directories, it made sense to have the container contain a Sea= rch_Type component, and the Iterator type to contain a Directory_Entry comp= onent, which contains the current directory entry for the loop. The Next fu= nction needs to update its Directory_Entry component to get the next direct= ory entry, so it needs read-write access. I was able to work around this by using the Rosen trick to acquire read-wri= te access to the "in" parameters for these functions. However, this is awkw= ard, and it tells me that we have the wrong interfaces for iterators, or at= least we have missing interfaces. One shouldn't have to jump through such = hoops to write iterators for abstract data types. Brad >=20 > Can I use the same iterator more than once? (so long as the container > hasn't changed, of course - I expect that would count as tampering, > though) If so, that'd explain why Next.Object is an in parameter!