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.213.99 with SMTP id nr3mr4435246pbc.2.1324067773223; Fri, 16 Dec 2011 12:36:13 -0800 (PST) Path: lh20ni30324pbb.0!nntp.google.com!news2.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!spln!extra.newsguy.com!feeds.phibee-telecom.net!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!border1.nntp.ams2.giganews.com!border3.nntp.ams.giganews.com!Xl.tags.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!local2.nntp.ams.giganews.com!nntp.bt.com!news.bt.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 16 Dec 2011 14:36:12 -0600 User-Agent: NewsTap/3.5.1 (iPad) From: Martin Dowie Newsgroups: comp.lang.ada Mime-Version: 1.0 Message-ID: <1882098503345759898.345166martin-re.mo.ve.thedowies.com@news.btinternet.com> Subject: Re: Ada2012 : When to use expression functions rather than function bodies? References: Date: Fri, 16 Dec 2011 14:36:12 -0600 X-Usenet-Provider: http://www.giganews.com X-AuthenticatedUsername: NoAuthUser X-Trace: sv3-6SqlukXaNewMBXYjiw5pZDBKlj7IX1fjbEy1mTOGOnWBI4f1e5shfXqAFZpXIsrS2V71E+8qSD0NZHL!JmMMzH+sBuCZbiCjLqbkkQpi/BkDs7HF5afTEGdFT5LF0j4Qhhvm07UrhrEvw9aKBRx2YASc73TY!slVYs6GeBO0vb/KxR4MbGhK+4r9rUH59ivtS7DjbQ6dsmJ0= X-Complaints-To: abuse@btinternet.com X-DMCA-Complaints-To: abuse@btinternet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3993 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 2011-12-16T14:36:12-06:00 List-Id: 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. The visible part should, ideally, express > what the package is intended to accomplish, at a conceptual level. So > 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. A 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?" If 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. I 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. But 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. But the encapsulation argument could still apply if > the function is intended to be usable by child packages. > > -- Adam The most common usage I can image is functions used in Pre/Post conditions: package Foos is type Foo is tagged private; ... procedure Bar (Self : in out Foo) with Pre => Is_Valid (Self); function Is_Valid (Self : Foo) return Boolean; ... private ... function Is_Valid (Self : Foo) return Boolean is (); ... end Foos; There isn't really an expectation that Is_Valid would be of use to a user of package Foos. But I guess the same idiom could be used for other 'simple' functions...public declaration, private expression function implementation, leaving the package body of more interesting stuff. -- Martin -- -- Sent from my iPad