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-Thread: a07f3367d7,7ff1de84a8945e80 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Access types as parameters References: <521c4843-d40f-4545-9e80-ca725e847090@h21g2000yqa.googlegroups.com> <8410fc60-9b8a-4f82-92fc-622a6bbe5931@i18g2000pro.googlegroups.com> <8880c3d0-a07f-4d4e-ac87-372014598576@d15g2000prc.googlegroups.com> From: Stephen Leake Date: Tue, 18 Aug 2009 08:22:30 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) Cancel-Lock: sha1:3qPbyY+aUpaqB+GriQlEkDpyceo= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: db2374a8a9cfce197caa713449 Xref: g2news2.google.com comp.lang.ada:7849 Date: 2009-08-18T08:22:30-04:00 List-Id: "Randy Brukardt" writes: > "Stephen Leake" wrote in message > news:uprb1epp8.fsf@stephe-leake.org... > >> To be convincing, I'd have to post an example from Gtk or OpenToken >> written both ways; maybe later I'll find time for that. > > Yeah, I know that we are both talking rather hypothetically, and we may have > rather different examples in mind. I've now written a small example of the two styles; see http://www.stephe-leake.org/ada/access_vs_object.html The problem domain of this example is grammars; the goal of the application is to allow the user to build a data structure that represents a grammar, so the application can then use that structure to parse input strings. Typical grammars have recursion in them. This requires pointers of some form in the data structure. The access_style package tree in this example uses explicit access types as the pointers, and access parameters in the relevant grammar constructing functions. The object_style package tree uses Ada.Containers Cursors as the pointers. The object style contains a significant kludge; there is a global (but private, in Object_Style.Pointers spec) List object that holds all the tokens needed for the grammar. That was the only way I could see to get a Cursor for each. AI05-0069-1 (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0069-1.txt) defines holder containers that should eliminate this kludge in Ada 201z. In addition, in Object_Style.Sequence "&" body, we must examine the tag of the arguments, rather than using dispatching to achieve the same result. This doesn't happen in the access style, because we can define two "&" functions with different type profiles; one takes a token object, the other an access to class-wide. Finally, some type information is lost with this style. Compare object_style-run.adb to access_style-run.adb; there are more precise types in the access style version. In the full OpenToken application, this becomes even more significant. There are two main objections to the access style: 1) Users must manage memory 2) If users pass in access values with nested accessibility, they will get Program_Error at run-time. The first objection can be mitigated by realizing that there is never any need (in this application) to deallocate any of the grammar structures. This could be made explicit with a new pragma No_Deallocation, applied to the access types. The second objection can be eliminated by adding preconditions to the subprograms that take access parameters, as defined by ai05-0145-1 and ai05-0024-1: pragma Inherited_Precondition ("&", Left in Access_Style.Token_Access_Type); A reasonably smart compiler can then report the accessibility errors at compile time rather than runtime. A third style would be a modification of the access style; define the access type storage_size to be zero, so that no allocations (or deallocations) can be done. This forces the user to define aliased grammar objects on the stack at library level, and then reference them in other grammar objects via 'access. That is significantly more awkward than allowing allocation, but not deallocation. With the facilities of Ada 201z, I believe using explicit access types and access parameters is the best fit to the problem domain. Using container Cursors as the pointers is awkward, loses type information, and doesn't gain enough to be worth it. This thread originally started discussing Gtk, which also uses access parameters. In my (few, small) Gtk applications, I don't deallocate Gtk widgets; I create them all at the start, and then show and hide them as appropriate. So I could live with a Gtk that had pragma No_Deallocations on the access types. Other people might object to that, though :). -- -- Stephe