CheckedConsumer with more than one param

[galegofer]

Hello,

Is there any reason why we have a CheckedConsumer with just one parameter, and not like the CheckedFunctionX interfaces with several ones?, I mean CheckedConsumer<A, B, C,...>?.

Just curious.

Thanks

[hamnis]

For all your parameter needs, you can take a look at https://github.com/hamnis/arities
Code generation for all types of function arities, tuples, and some checked variants thrown in for good measure.

[danieldietrich]

Hi @galegofer,
the reason is that there is no Vavr API that makes use of these interfaces.
I would suggest to define your own interfaces, especially if you need to expose them as part of a public API (high cohesion & under own control).
The main idea is that a BiConsumer<T, U> is the same as a Function<T, U, void>.
I hope that Java will eventually allow primitive generics.

[danieldietrich]

Vavr will not support CheckedConsumers.
I think this is a dead end. When we have primitive generics, a CheckedConsumerN might be expressed like this:

CheckedFunctionN<any T1, ..., any Tn, void>

[galegofer]

Hi Daniel,

Thanks for the quick answer, and sorry for the late response.
About a CheckedConsumerN, I think what you said about getting rid of them at VAVR 1.0.x is a good idea.
Anyway, I think given VAVR 0.9.x is quite popular, and those interfaces are handy, why not to provide something to give more cohesion rather than to be in need to create an artificial interface just for a special case, I mean compare a code like:

private final CheckedFunction2<T, U, Void> dummy = (t, u) -> {
     mycode... Throws exception
     
     return null;
}

with:

private final CheckedConsumer2<T, U> dummy = (t, u) -> {
     mycode ...   
}

I think that to return null, just to don't have an interface makes the code less readable and given we have these kinds of interfaces at VAVR 0.9.x, why no to add another one (n indeed) that's will help us to make the code more concise?.

Another question that is arising in my head, what's going to happen with VAVR 0.9.x branch, I mean, given VAVR 1.0.x is not going to be backward compatible with 0.9.x, does it means that 0.9.x maintenance will finish? or 0.9.x will have eventually a release to a major version (not just to 0.10.x)?
Maybe a VAVR 1.0.x should be the name for the line of 0.9.x and VAVR 1.0.x should go to 2.0.X? just my 20 cents.

[danieldietrich]

@galegofer, please find my thoughts about Vavr support here: http://blog.vavr.io/vavr-support-roadmap/

In Java there will be primitive generics

Function<T, void>

which would make CheckedConsumers obsolete. I suggest to write your own FIs for that purpose, they are each only 3 LOC.

[galegofer]

I didn't know about Java with primitive generics, that's amazing, so it makes sense what you said.

Thanks!

[cebaa]

@danieldietrich When you say "In Java there will be primitive generics", you meant https://openjdk.java.net/jeps/218?

[danieldietrich]

Yes