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.107.82.26 with SMTP id g26mr9144507iob.38.1516957760943; Fri, 26 Jan 2018 01:09:20 -0800 (PST) X-Received: by 10.157.85.15 with SMTP id l15mr1011793oth.12.1516957760625; Fri, 26 Jan 2018 01:09:20 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!w142no826299ita.0!news-out.google.com!b73ni938ita.0!nntp.google.com!g80no827768itg.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 26 Jan 2018 01:09:20 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=176.130.29.212; posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH NNTP-Posting-Host: 176.130.29.212 References: <61ba3677-0041-4dba-af9b-a5df48f3ce8a@googlegroups.com> <6427a793-91a4-4feb-b067-ed89b4c04421@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3af9cfc4-d434-4d60-a4ed-17a16f75717f@googlegroups.com> Subject: Re: Iterable container as generic parameter From: briot.emmanuel@gmail.com Injection-Date: Fri, 26 Jan 2018 09:09:20 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 2172572786 X-Received-Bytes: 3732 Xref: reader02.eternal-september.org comp.lang.ada:50161 Date: 2018-01-26T01:09:20-08:00 List-Id: > But I probably would just use your original spec and add the container ty= pe=20 > and iterator function, something like: >=20 > generic > type Cursor is (<>); > with function Image (C : Cursor) return String; > type Container (<>) is private; > with package Iterator_Interfaces is > new Ada.Iterator_Interfaces (Cursor, others =3D> <>); > with function Iterator (C : Container) return=20 > Iterator_Interfaces.Forward_Iterator'Class; > function List_Image return String; >=20 I think that's a good starting point. When this works, and if you have a similar need for another algorithm, then= you can start thinking of signature packages and introduce some of them. I started my work on the traits containers when I wanted to write algorithm= s that would work for any of the standard containers (later on I realized t= hat those containers, at least in the GNAT implementation) had a lot of dup= licate code between definite/indefinite variants, that could be factored aw= ay with an Elements traits package, so I introduced that. And so on. I definitely agree with Randy here that we should not construct signature p= ackages in the abstract, but start from existing and working code. The only drawback is that introducing them breaks the existing API: - instantiating the generic now uses different set of formals. We have proposed http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai= 12-0205-1.txt?rev=3D1.2&raw=3DN for the next revision of the language, whic= h might help a little - moving out some code out of an existing package and into a generic mea= ns you need to introduce a lot of renamings to preserve existing API. We have proposed http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai1= 2-0229-1.txt?rev=3D1.3&raw=3DN to help. I recently made changes to GNATCOLL so that people could chose which kind o= f reference counting they want to use for GNATCOLL.Strings. Either no count= er (in which case we don't do copy-on-write), non-atomic counters or atomic= counters. This could only be done via a signature package, since declaring= a type with aspect "Atomic" generates some memory fence operations which a= re slow. That leads to a 3 to 4% speed improvement. Just another example of= possible signature package. Emmanuel