This article is a follow up to the one about functional concepts, suggested by @pcolomb. As I’m not
yet fully aware of Java 8 lambda to add snippets, I decided to present a way to
simulate these concepts in pure Java.
The proposed version is not really usable, and probably performs badly, but
can help to understand the underlying concepts (and it’s fun).
As explained in the previous
article, lambda are anonymous functions, that can be created
on demand. We’ll create a class that simulate an unary function.
We thus need to create a generic class simulating anonymous
function creation, having A → B as signature. This can be defined
as:
It works! To better integrate this, it would be nice that the
“function” implements Callable, which would allow to use it in a
context needing this interface. Let’s try to modify our class accordingly.
Since the argument can’t be given to call, we must keep it in the
object’s internal state, as a private attribute.
Note the Function<A,R> bind(A arg) method, having a
fluent interface flavour, allowing to easily chain methods. This
bind method is equivalent to partialize the function,
that can therefore be called without arguments, and thus follow the
Callable interface. This partial application corresponds to a
closure, the closed variable being kept in a function private attribute.
Finally, call overloading makes the use of the function more
natural, keeping the interface compatibility at the same time (beware the
internal side effect, since the object state is changed).
We just thus simulated a closure allowing a partial
application.
The Function object gives us unary functions, which is
somewhat limited. How can we create functions with several arguments? We could
create a generic class for every arity, but there is a simpler solution: create
curryfied functions, that is a function of
just one argument, returning a function of just one argument, etc.
It is already possible “by hand”, with what we have. Let’s create a
function add: Interger → Integer → Integer with our first lambda
version.
Not really readable, but it works. Note that arguments (at least
a must be finals, since they are used in an anonymous inner class;
but hey, we are doing functional programming right?
On fait ici une « vrai » fermeture, au sens fonctionnel, puisque la variable
a est bien capturée directement dans la définition de la fonction
interne ; mais notre fonction n’est plus Callable. On est ici très
proche de la version Javascript de
curryfication simple.
This one is a “true” functional closure, since the a
variable is captured in the internal function definition; but this function is
no more Callable. This approach is very similar to the Javascript one.
Let’s use our Callable version of
Function:
Ouch! It hurts, but it works, and with the previous features.
And what if we want both? The “ease” of function definition and the
greater flexibility? In object oriented paradigm, we would use
delegation, in functional programming, it’s called function
composition, but it’s the same principle. Let’s create a “function”
that takes a function and returns partial, augmented with the second approach
methods. It’s the decorator pattern from a functional point of view
(it’s the name used is Python world for such a thing). It’s the same approach,
but instead of redefining callMe, we create a fun
attribute containing a function that will be called with the arg
value (thus the delegation).