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.74.201 with SMTP id w9mr7367659pbv.0.1324076904081; Fri, 16 Dec 2011 15:08:24 -0800 (PST) Path: lh20ni30724pbb.0!nntp.google.com!news2.google.com!postnews.google.com!q9g2000yqe.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 15:08:13 -0800 (PST) Organization: http://groups.google.com Message-ID: <788ad3fb-08e5-43db-9839-3d2f3c979b21@q9g2000yqe.googlegroups.com> References: <1882098503345759898.345166martin-re.mo.ve.thedowies.com@news.btinternet.com> <954126f8-a43f-4451-9db2-20db1db05851@f33g2000yqh.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1324076897 26655 127.0.0.1 (16 Dec 2011 23:08:17 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 16 Dec 2011 23:08:17 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: q9g2000yqe.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-16T15:08:13-08:00 List-Id: On Dec 16, 1:34=A0pm, Adam Beneschan wrote: > On Dec 16, 12:36=A0pm, Martin Dowie > wrote: I 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. = =A0So > > > 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 "prop= er > > > 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" i= n > > > 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 i= n > > > the *private* part of a package with an expression function if the > > > body is simple. =A0But the encapsulation argument could still apply i= f > > > 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 conditi= ons: > > > 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 us= er > > 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. =A0Offhand, 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. On thinking about it further: A good reason *not* to put an expression function in the private part of a specification, if the function is an "implementation detail", is that if the details of the implementation are mostly in the package body (in procedures or in more complex functions), then moving some of it arbitrarily to the private part, which is separate from the package body and is often in a different source file, can impair readability and maintainability. When a programmer is trying to maintain a package, either by adding new features, improving performance, or fixing problems, it's helpful for related pieces of information about the package's implementation to be near each other. Otherwise, it's too easy to miss something. And moving one implementation detail to a package's private part while other details are still in the body increases the chance of missing something. So yes, I think there is a good argument for *not* mechanically moving all simple functions to the package specification as expression functions, even into the private part. The programmer needs to think about readability/maintainability issues such as I've described. -- Adam