Add support for a HighJ flavour about derive4j HOT 7 CLOSED

@DanielGronau, @clinuxrulz: I found that the constructor methods of Either and Maybe are a bit verbose, do you plan to keep them as is or would you rather drop the 'new' prefix to be more in line with other fp libraires?

I ask because the name of the methods will be hard-coded in derive4j (as well as the qualified name of Maybe, Either and F1). So it would be better if they not change just after the derive4j release.

from derive4j.

The constructor methods started actually as Left, Right, Just, Nothing, I changed them to to follow the Java convention of small method names (and couldn't bring myself to call them left, right etc).

However, I have no strong opinion about this, and wouldn't mind to switch back to the old uppercase names. Then there is still the question concerning the lazy counterparts. I found out that using the same name for a lazy version passing a Supplier is a bad idea.

Concerning the package structure, I'm inclined to drop the data package, and reorganize the packages inside (which look quite messy right now). I would also drop all plurals in package names. So we would end up with org.highj.collection.Either, org.highj.collection.Maybe and org.highj.function.F1

from derive4j.

yes, using the same name for the lazy constructor can break method reference type inference.

@DanielGronau could you drop me a note in this issue when the HighJ has settled on those points ?

from derive4j.

@jbgi We moved Maybe and Either to org.highj.data, and F1 to org.highj.function. Further, we changed the constructor methods to upper-case.

from derive4j.

@DanielGronau perfect. Need to sort out #34 and #35 and will release 0.9 shortly!

from derive4j.

@clinuxrulz @DanielGronau Derive4J 0.8 with the HighJ flavour should now be available on maven central!

from derive4j.

Thank you, I updated the dependency.

from derive4j.