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.75.170 with SMTP id d10mr9335330pbw.6.1324058588281; Fri, 16 Dec 2011 10:03:08 -0800 (PST) Path: lh20ni29907pbb.0!nntp.google.com!news1.google.com!postnews.google.com!p16g2000yqd.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 10:03:07 -0800 (PST) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1324058588 1205 127.0.0.1 (16 Dec 2011 18:03:08 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 16 Dec 2011 18:03:08 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: p16g2000yqd.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-16T10:03:07-08:00 List-Id: On Dec 16, 4:25=A0am, 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