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: a07f3367d7,9983e856ed268154 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Received: by 10.216.235.32 with SMTP id t32mr678996weq.7.1344849645512; Mon, 13 Aug 2012 02:20:45 -0700 (PDT) Path: n2ni107168540win.0!nntp.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!xlned.com!feeder3.xlned.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!80.86.168.138.MISMATCH!news-feed.eu.lambdanet.net!news.bcc.de!newsfeeder.ewetel.de!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 07 Aug 2012 15:41:05 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> <502005b6$0$9510$9b4e6d93@newsspool1.arcor-online.net> <50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net> <5020e0e1$0$6570$9b4e6d93@newsspool3.arcor-online.net> In-Reply-To: Message-ID: <50211aed$0$6571$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 07 Aug 2012 15:41:01 CEST NNTP-Posting-Host: a931d891.newsspool3.arcor-online.net X-Trace: DXC=lOT^T6nYE8A74okIm;?DS@McF=Q^Z^V3H4Fo<]lROoRA8kFJLh>_cHTX3jMV0865cPR^KI X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 2012-08-07T15:41:01+02:00 List-Id: On 07.08.12 15:09, Vasiliy Molostov wrote: > Georg Bauhaus писал(а) в своём письме Tue, 07 > Aug 2012 13:33:21 +0400: > >> On 07.08.12 01:09, Vasiliy Molostov wrote: > ..... >> Hence, the place where others want to learn how to call a >> subprogram is not the place for aspects that apply in very >> specific circumstances only. They never affect the text >> of the call statement. >> > > Perhaps I am a bad reader but you have not explained - what the benefit to > place Inline in a private part. Premise 1: The reader is the only important person in Ada programming. Premise 2: The reader wishes to learn from a package spec how to write a call statement (essential knowledge: profile, contract, exceptions). ==== Conclusion: Anything that does not answer the reader's questions as stated in premise 2 is in excess of what is needed, in general, and not beneficial. > Why convention is an optimisation? <- "you still have unanswered question here" I have answered this question twice. Specifically, I have likened the two and pointed to the ground on which the two aspects compare. I have *not* said that convention *is* optimization, or vice versa. You may have read this into my comparison of the reader's attitude towards both, I think. Again, if Ada.Strings.Fixed.Move has something with convention C, then as the reader of Ada.Strings.Fixed I not only need not care about that, thanks to Ada's separation of spec, I don't want to be bothered with whatever mechanism is used to make Move work. I want to be able to write Move, and know what this does. > Other things in your replacas while they are good in common I consider as > demagogy here, sorry. My impression is that you generalize a style that is useful in your specific circumstances. I can't accept that as generally useful and not as economically viable. Reason: I am the one who always has to do the clean-up after a "pragmatic, cool" programmer has left a company and I know the time it takes to make things work in general, again. Jobs: "Get this code to work in the new surroundings." "Turn that clever hack into something that works when Xyz changes", etc. You get allergic to things that should be general, like a subprogram spec, but aren't because they were written "pragmatically", and it takes time to sort out which aspects are essential (influence the program's output) and which aspects aren't.