Re: Ada2012 : When to use expression functions rather than function bodies?

[Martin Dowie <martin@re.mo.ve.thedowies.com>]

Adam Beneschan <adam@irvine.com> wrote:
> On Dec 16, 4:25 am, Martin <mar...@thedowies.com> 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 (<validate_Self>);
   ...
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