Richard Finegan - 1 year ago 215

Java Question

I see java.util.function.BiFunction, so I can do this:

`BiFunction<Integer, Integer, Integer> f = (x, y) -> { return 0; };`

What if that is not good enough and I need TriFunction? It doesn't exist!

`TriFunction<Integer, Integer, Integer, Integer> f = (x, y, z) -> { return 0; };`

I guess I should add that I know I can define my own TriFunction, I'm just trying to understand the rationale behind not including it in the standard library.

Answer Source

As far as I know, there are only two kinds of functions, destructive and constructive.

While constructive function, as the name implies, constructs something, a destructive one destroys something, but not in the way you may think now.

For example, the function

```
Function<Integer,Integer> f = (x,y) -> x + y
```

is a **constructive** one.
As you need to or do construct something. In the example
you constructed the tuple *(x,y)*. Constructive functions have the problem,
of being not able to handle infinite arguments. But the worst thing is, you
can't just leave an argument open. You can't just say "well, let x := 1" and try out
every y you may like to try. You have to construct every time the whole tuple with
`x := 1`

. So if you like to see what the functions return for `y := 1, y := 2, y := 3`

you
have to write `f(1,1) , f(1,2) , f(1,3)`

.

In Java 8, constructive functions should be handled (most of the time) by using Methodreferences because there's not much advantage of using a constructive lambda function. They are a bit like static methods. You can use them, but they have no real state.

The other type is the destructive one, it takes something and dismantles it as far as need.
For example, the **destructive** function

```
Function<Integer, Function<Integer, Integer>> g = x -> (y -> x + y)
```

does the same as the function `f`

which was constructive. The benefits of a destructive function are, you
can handle now infinite arguments, which is especially convenient for streams, and you can just leave arguments open.
So if you again want to see what would the result be like if `x := 1`

and `y := 1 , y := 2 , y := 3`

, you can say `h = g(1)`

and
`h(1)`

is the result for `y := 1`

, `h(2)`

for `y := 2`

and `h(3)`

for `y := 3`

.

So here you have a fixed state! That's quite dynamic and that's most of the time that what we want from a lambda.

Patterns like Factory are a lot easier if you can just put in a function which does the work for you.

Destructive ones are easily combineable with each other. If the type is right you can just compose them as you like. Using that, you can easily define morphism which makes (with immutable values) testing a lot easier!

You can do that too with constructive one, but a destructive compose looks nicer and more like a list or a decorator, and the constructive one looks a lot like a tree. And things like backtracking with constructive functions are just not nice. You can just save the partial functions of a destructive one (dynamic programming), and on "backtrack" just use the old destructive function. That makes code a lot smaller and better readable. With constructive functions you have more or less to remember all arguments, which can be a lot.

So why is there a need for `BiFunction`

should be more of question then why there is no `TriFunction`

?

First of all, a lot of time you just have a few values (less than 3) and need just a result, so a normal destructive function would be not needed at all, a constructive one would do fine. And there are things like monades which
really needs a constructive function. But aside from that, there are not really a lot of good reasons why there is a `BiFunction`

at all. Which doesn't mean it should be removed! I fight for my Monades until I die!

So if you have a lot of arguments, which you can't combine into a logical container class, and if you need the function to be constructive, use a method reference. Otherwise try to use the new gained ability of destructive functions, you may find yourself doing a lot of things with a lot less code lines.