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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,73175d2d01a1b1dd X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.46.193 with SMTP id x1mr4203236pbm.7.1317047388908; Mon, 26 Sep 2011 07:29:48 -0700 (PDT) Path: lh7ni5356pbb.0!nntp.google.com!news1.google.com!goblin2!goblin1!goblin.stu.neva.ru!feeder.news-service.com!feeder.news-service.com!xlned.com!feeder1.xlned.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Mon, 26 Sep 2011 16:29:47 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: subprogram must not be deeper than access type References: <818752663338654817.822041rmhost.bauhaus-maps.arcor.de@news.arcor.de> In-Reply-To: Message-ID: <4e808c5b$0$6622$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 26 Sep 2011 16:29:47 CEST NNTP-Posting-Host: 28b5ccad.newsspool2.arcor-online.net X-Trace: DXC=lS7`E\`jcla>jlK2>IgHGdA9EHlD;3Ycb4Fo<]lROoRa8kFjLh>_cHTX3jmI^VCQ\1>XUn X-Complaints-To: usenet-abuse@arcor.de Xref: news1.google.com comp.lang.ada:18129 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2011-09-26T16:29:47+02:00 List-Id: On 26.09.11 11:45, Natasha Kerensikova wrote: >> Also, whenever an anonymous type >> seems to solve a design problem, >> something might be in bad shape >> at a higher level. > > Actually I wonder whether there is a design problem at all. Just a design choice. In general, I should think that if an author too quickly arrives at pointers, some C heritage shows. I can really picture the structs and function pointers, I think :-) If you have an object of type String_Accumulator_Linked_List (Builder : Accumulator_Builder) is new String_Accumulator_Stack with private; then the Builder component is fixed. Fine. Presumably, the operations of String_Accumulator_Linked_List call Builder as necessary. So Builder has to be in scope where they do that. For making Builder visible, an access discriminant pointing to a function is a possible choice; there are more ways of making a function visible, not necessarily worse or better, but they may save some trouble or be of different efficiency, or clarity. One is scoping. Another is instantiation of a suitable generic, one that declares a simpler String_Accumulator_Linked_List. At the other end, a factory like Accumulator_Builder might (or might not) deserve a type of its own. The implementation of the operations of String_Accumulator_Linked_List would again be able to request new accumulators from the factory, but this time through operations of this factory type, adjusted, modified, varied, as needed. For example, a task could supply the list with new accumulators from some foreign pool, and could shape the accumulators as requested. (The shapes being configured when setting up the factory, or while it is operating already.) I'd make a factory object a by-reference type if copying is a concern, and try to avoid indirection without need. One way to do away with a pointer to the factory is to have the core algorithm subprogram take a factory parameter: procedure Do_Stuff (Factory : Accumulator_Builder; ...) The invisible difference here is that Accumulator_Builder would not have to be a pointer. > Having read the Rationale 2005, I understand now that naming an access > type is far from being equivalent to text replacement. A slightly less > readable program text is a small price to pay for the extra safety. As I understand it, anonymous pointers (a) enable references to nested subprograms in ways just not possible before their introduction, and (b) circumvent problems with conversions-to-named and with implementation techniques. So there wouldn't be an argument about safety, or is there?