Re: Functional vs imperative style
On 27.08.14 09.47, Paavo Helde wrote:
This is about a class interface design. Let's say I have an Array class
which is able to encapsulate a N-dimensional array of a dynamic element
type and has runtime operations for resizing the dimensions, converting
the element type, etc.
Should these operations be const member functions returning a new Array
(functional style) or non-const void member functions modifying the
object? The actual content is shared and reference-counted behind the
scenes so just copying an Array object is pretty cheap, so this question
is more about style, not performance, thus I am mostly leaving out
optimization issues here.
If there are no serious performance issues, which is by far not always
true for tensor classes, I would prefer the functional style. From my
experience it is less sensitive to aliasing errors.
In case of element type conversions you have no options anyway.
Drawbacks:
- Deviates from the std::vector usage (e.g. std::vector::resize()).
- The caller may forgot to assign the result to a new object and assume
the modifications happen in place
Well, this will usually be fixed after the first test.
Advantages:
- Follows std::vector design
For std::vector the performance problem is a real issue, especially if
the element's copy constructor is non-trivial.
Drawbacks:
- More verbose usage
- Code is less robust because of side effects
- Worse optimization possibilities because unneeded named objects tend
to remain lying around.
ACK.
So, any comments or insights?
There is another issue that might be related: concurrency. On nowadays
hardware this is more and more an issue.
Immutable objects are one of the safest ways to deal with concurrency
issues. Furthermore they might be safely duplicated e.g. for NUMA
architectures. I think these aspects will become more and more an issue.
All you have to do is to make the reference counters thread-safe. And
maybe COW which is quite simple too because a read of reference count 1
is always thread safe (with acquire semantics).
But all of this can only be extended if your API is functional. Once you
have gone the old style, the game is over.
Furthermore making an functional API imperative is quite easy. Just swap
the result with the first argument.
Which style should I aim for? This
interface is intended for external library users, but at the moment we
don't have any yet, so cannot ask directly. Which style would *you*
prefer when given the task to accomplish something by such a library?
For calculations I prefer the functional style. It is more closely to
the mathematics. In place is primarily an optimization issue due to real
existing hardware and software.
Maybe I should provide both styles?
This is the way tho Wolfram language has gone. There is an AppendTo and
an Append function. The first operates in place. This is quite funny
since it is a mainly functional language.
They would probably need different
member function names, are there any naming conventions for these
different styles?
I only know the above example for an API that provides both flavors.
Marcel