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

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1s7pzkf4hmdl5.15o0cmwoy5alh$.dlg@40tude.net...
> On Fri, 16 Dec 2011 04:25:09 -0800 (PST), 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?
>
> 1. Readability
> 2. Proper encapsulation (to have interface and implementation separated)
> 3. Re-use (the same function must be refactored)
> 4. Maintainability (because of 1..3)
> 5. Safety (proper bodies are defined on the context where they have no
> access to the caller's context, otherwise than through parameters)
> 6. Deployment (proper bodies can be put into a library, have versions etc)
> 7. It is not Ada

Umm, an expression function is just another (shorter) way to write a 
function body, so it hard to imagine that there is any difference. Using 
them to replace a function body *in place* is completely harmless.

I suppose you are talking about the use of expression functions directly in 
a specification (without an explicit body), which is a totally separate 
issue. There, I tend to agree with you in the sense that they ought to be 
used in moderation. The intent was to use them for things like accessors for 
private components where there is no real value to the separate body.

For those sorts of uses, the issues you talk about above don't arise. (How 
could you "refactor" Obj.Field??). Moreover, everything in the private part 
is part of the implementation anyway; you're still enforcing that separation 
so long as the expression functions are in the private part.

                           Randy.