Additionnal facilities for partial matching

[jbgi]

today there is only

Function<ADT, R> otherwise(Supplier<R> expression)

I think it should be renamed into

Function<ADT, R> otherwiseEval(Supplier<R> expression)

And then we can add:

Function<ADT, R> otherwise(R value)
Function<ADT, Option<R>> otherwiseNone()
Function<ADT, Either<L, R>> <L> otherwiseLeft(L leftValue)
Function<ADT, Validation<E, R>> <E> otherwiseFail(E error)

What others think about that feature? (are naming good?)

[talios]

Would otherwiseLeft and otherwiseFail only be generated for the flavours that support them, or will derive4j have a companion artefact containing an Either and Validation implementation ( hopefully not unique versions of these per @Data type..

[talios]

Would otherwiseLeft and otherwiseFail only be generated for the flavours that support them, or will derive4j have a companion artefact containing an Either and Validation implementation ( hopefully not unique versions of these per @Data type..

[jbgi]

they would be generated only for flavours that already have those data-types.

[jbgi]

they would be generated only for flavours that already have those data-types.

[talios]

+2 - sounds good.

[talios]

+2 - sounds good.

[elucash]

2cents: why not have overload?

Function<ADT, R> otherwise(R value);
Function<ADT, R> otherwise(Supplier<R> value);

Things are only going bad if you have same erasure or ambiguous lambda parameter (Supplier<Supplier<>> ? unlikely to be used). And the symmetry is not harmed either as naming here is to accommodate return type, not input

[elucash]

2cents: why not have overload?

Function<ADT, R> otherwise(R value);
Function<ADT, R> otherwise(Supplier<R> value);

Things are only going bad if you have same erasure or ambiguous lambda parameter (Supplier<Supplier<>> ? unlikely to be used). And the symmetry is not harmed either as naming here is to accommodate return type, not input

[jbgi]

Yeah, let's try overloading. If not complaints from users' compilers we will keep it. thanks @elucash

[jbgi]

Yeah, let's try overloading. If not complaints from users' compilers we will keep it. thanks @elucash

[jbgi]

overloading may not be a good idea, performance-wise. Current inference algo is slow in the presence of overloading: https://bugs.openjdk.java.net/browse/JDK-8051946 / http://stackoverflow.com/questions/34223249/slow-compilation-with-jooq-3-6-plain-sql-and-the-javac-compiler
I also worry that IDE code completion will be less useful.

[jbgi]

overloading may not be a good idea, performance-wise. Current inference algo is slow in the presence of overloading: https://bugs.openjdk.java.net/browse/JDK-8051946 / http://stackoverflow.com/questions/34223249/slow-compilation-with-jooq-3-6-plain-sql-and-the-javac-compiler
I also worry that IDE code completion will be less useful.

[jbgi]

I left out otherwiseFail (Validation ), to reduce the amount of generated code (conversion from Either is easy).
I also gone the overload route. If problems arise overloads may be renamed in a later version.

[jbgi]

I left out otherwiseFail (Validation ), to reduce the amount of generated code (conversion from Either is easy).
I also gone the overload route. If problems arise overloads may be renamed in a later version.