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: 103376,7ae8393ad9100e97 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.189.194 with SMTP id gk2mr10345445pbc.3.1324084908727; Fri, 16 Dec 2011 17:21:48 -0800 (PST) MIME-Version: 1.0 Path: lh20ni31085pbb.0!nntp.google.com!news1.google.com!news.glorb.com!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada2012 : When to use expression functions rather than function bodies? Date: Fri, 16 Dec 2011 19:21:45 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <12acbf57-01fc-43dd-8881-d39c2a63146b@q9g2000yqe.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1324084907 12735 69.95.181.76 (17 Dec 2011 01:21:47 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 17 Dec 2011 01:21:47 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2011-12-16T19:21:45-06:00 List-Id: "Adam Beneschan" wrote in message news:12acbf57-01fc-43dd-8881-d39c2a63146b@q9g2000yqe.googlegroups.com... ... >Apparently the ARG thought this was a good argument. I'm not >endorsing it personally -- I don't have a particular opinion -- but it >appears sensible on its face. One of the things we learned when thinking about Preconditions and the like is that there is such a thing as too much encapsulation. The entire point of preconditions is that they be understandable to the client, so the client (caller) knows what they must ensure before calling the routine. You could write all of your preconditions like: procedure Do_It (A, B : in out Integer) with Pre => Do_It_Precondition (A, B); but no one would have any idea what the precondition is. After all, an important part of the point of preconditions is to change what currently is specified in English in the comments in a more formal way that can be checked (statically and dynamically). So it is best to use as little encapsulation as possible in preconditions and the like, breaking them down to the primitive operations of the type(s) involved. But preconditions can get very long, and the need to simplify them for readability surely exists. Thus expression functions provide a middle ground. They're also handy for simple accessor functions (which can give the effect of read-only components of a private type). There also is one more fact: an expression function can almost always be inlined (beware of recursion, though), and that can be done automatically when it makes sense (no need for pragmas or body dependencies -- inlining is something the compiler should be deciding upon anyway, it is stupid for users to have to declare something that should always be done if it makes sense -- and not be done when it doesn't make sense). Randy.