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

[Adam Beneschan <adam@irvine.com>]

On Dec 16, 12:36 pm, Martin Dowie <mar...@re.mo.ve.thedowies.com>
wrote:
> Adam Beneschan <a...@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.

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