Codecov Report

Merging #331 into master will increase coverage by 0.11%.
The diff coverage is 86.66%.

@@            Coverage Diff             @@
##           master     #331      +/-   ##
==========================================
+ Coverage    39.4%   39.52%   +0.11%     
==========================================
  Files         178      178              
  Lines        9245     9260      +15     
  Branches      523      524       +1     
==========================================
+ Hits         3643     3660      +17     
+ Misses       5449     5448       -1     
+ Partials      153      152       -1

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e0f69dc...16263e8. Read the comment docs.

On a scale 1 to 10, how alive is this project?

On a scale 1 to 10, how alive is this project?

I am glad of your optimism shown by not including 0 ;)
But yeah, realistically there is currently few active maintainers so I would say maybe 4 on your scale currently.
I personally try to review PR as quickly as possible, but a recent new-born is taking a lot of my free time.
We are of course welcoming new contributors such as your-self.

A for this current PR, I actually had a look a some times ago, but forgot to get back to you, sorry.
I was pondering if those combinators would be better suited for F2<A, A, Boolean> and be in placed in Booleans.java?
Or, alternatively, I'd rather have them on the Definition interface.

The reason is that I see Equal as a type class, and as such it would feel weird to have multiple instances of Equal<Foo> in scope as this will be required for using thoses new methods.

how does that sound?

I thought it would be more convenient to have these methods as members, cause it feels natural to call it on Equal.
Also, contramap function basically works the same way.
We can look at methods like this as a functions in the same module as type class. I actually don't see a big difference between this and putting methods like map and filter inside Stream class.
IMHO, type classes and data types are pretty similar in this respect: we define class or data and then we write some functions that use our class or data. In functional languages like haskell we put it in the same module, in OO language we put it in the same class.

And I also like the way it works in java Comparator interface :)

What do you think?

Yeah, that's probably fine. I think andThen in particular is useful, not sure if there is real use cases for the others though, do you have one?
I will wait for another contributor to give 👍 and will merge. (//cc @orionll @tonymorris)

"and" and "andThen" are pretty similar, the difference is more philosophical. You would want to use "and" if both Equals are equally important and "andThen" when first Equal is more important and you want to emphasize it.
I couldn't think of any real use cases for "or". I would still keep it for symmetry, but it's ok if you want to remove it.

@jgbi Are you OK with keeping the methods? Thanks

@l1cache @gliptak I pushed slightly different approach on #333, keeping only the andThen APIs, and avoiding intermediate, partially defined, Equal or Ord instances. Please comment on it.

Closing in favor of #333 (that will be merged soon if no objection)