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 Received: by 10.68.191.41 with SMTP id gv9mr9888838pbc.5.1324071381116; Fri, 16 Dec 2011 13:36:21 -0800 (PST) Path: lh20ni30485pbb.0!nntp.google.com!news2.google.com!postnews.google.com!f33g2000yqh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Ada2012 : When to use expression functions rather than function bodies? Date: Fri, 16 Dec 2011 13:34:51 -0800 (PST) Organization: http://groups.google.com Message-ID: <954126f8-a43f-4451-9db2-20db1db05851@f33g2000yqh.googlegroups.com> References: <1882098503345759898.345166martin-re.mo.ve.thedowies.com@news.btinternet.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1324071380 2478 127.0.0.1 (16 Dec 2011 21:36:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 16 Dec 2011 21:36:20 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: f33g2000yqh.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUEHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2011-12-16T13:34:51-08:00 List-Id: On Dec 16, 12:36=A0pm, Martin Dowie wrote: > Adam Beneschan wrote: > > On Dec 16, 4:25 am, Martin wrote: > >> Are there any good arguments for *not* replacing all simple, single > >> line functions that don't [directly] access package body state > >> information with expression functions? > > > If you're talking about a function that is declared in the visible > > part of a package specification, and talking about replacing the > > declaration with an expression function, then it would usually be a > > bad idea to replace it. =A0The visible part should, ideally, express > > what the package is intended to accomplish, at a conceptual level. =A0S= o > > unless the expression is, itself, part of the concept (a rare case), > > it's an implementation detail that should not be present in the > > visible part of a package. =A0A good test here, I think, is: "Is it > > possible that at some later point, I may change the expression > > returned by an expression function because I've added new features to > > the package or because I've changed the implementation to improve its > > efficiency or fix problems?" =A0If the answer is yes, then the > > expression is probably an implementation detail and not part of the > > package's "concept", and the function shouldn't be an expression > > function. =A0I think this is approximately what Dmitry means by "proper > > encapsulation". > > > Offhand, I don't see any problem with replacing simple function > > *bodies* with expression functions. =A0But I haven't studied the new > > rules carefully, so I couldn't tell you if there are some "gotchas" in > > the language rules that would cause the semantics or the impact on > > other language rules to be different. > > > In most cases, it's probably OK to replace a function specification in > > the *private* part of a package with an expression function if the > > body is simple. =A0But the encapsulation argument could still apply if > > the function is intended to be usable by child packages. > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Adam > > The most common usage I can image is functions used in Pre/Post condition= s: > > package Foos is > =A0 =A0type Foo is tagged private; > =A0 =A0... > =A0 =A0procedure Bar (Self : in out Foo) > =A0 =A0 =A0with Pre =3D> Is_Valid (Self); > =A0 =A0function Is_Valid (Self : Foo) return Boolean; > =A0 =A0... > private > =A0 =A0... > =A0 =A0function Is_Valid (Self : Foo) return Boolean is ()= ; > =A0 =A0... > end Foos; > > There isn't really an expectation that Is_Valid would be of use to a user > of package Foos. I don't see a problem (from a proper encapsulation standpoint) with putting the expression function in the private part. Like I said before, though, I haven't studied the new rules enough to know whether there could be any other problems caused by the language rules. Offhand, it seems possible that if the expression involves a call to a function in another package, there could be cases where moving the definition from the body to the specification could fail because a different elaboration order is required. -- Adam