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

[Adam Beneschan <adam@irvine.com>]

On Dec 16, 1:34 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Dec 16, 12:36 pm, Martin Dowie <mar...@re.mo.ve.thedowies.com>
> wrote:

I 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.

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