Cats Order needs an `orElseBy` combinator about cats HOT 8 OPEN

Seems like a good PR.

I don't know all the motivations for Order but I think it was that Ordering I believe was contravariant and scala had (or maybe has?) some issues with very surprising implicit resolution on contravariant type classes.

from cats.

I think it would be a great addition indeed.

However, I wonder why orElse and orElseBy were added to Ordering, but not PartialOrdering.
And whether we'd like to address it in PartialOrder instead.

from cats.

I wonder why orElse and orElseBy were added to Ordering, but not PartialOrdering

What would be the semantics of orElse etc when two elements are not comparable on the primary PartialOrder? ie tryCompare returns None. presumably theres no delegation for consistency. The name orElse could lead people to think it tries another PO if the first is incomparable.

That semantic does seem workable . Perhaps the slight ambiguity, or simply that PartialOrdering is less commonly used, is the reason.

from cats.

That's right. So I think that in theory, PartialOrder could offer two different orElse like combinators, e.g. orElseOnEqual and orElseOnUnrelated. Then in Order the former one should be simply inherited without changes, while the latter could short-circuit in order to simply return a result of "this" Order instance.

Not sure if all that makes sense though, wdyt?

from cats.

A precedent for Partial order orElse combinator

That's right. So I think that in theory, PartialOrder could offer two different orElse like combinators, e.g. orElseOnEqual and orElseOnUnrelated

I'm reluctant to implement a orElseOnUnrelated combinator without a clear use case.

Then in Order the former one should be simply inherited without changes

In spirit, yes. But partial orders return a comparison wrapped in an Option, while total orders omit the Option.

Interestingly, ZIO nicely avoids an Option by using a 4-branch sealed trait (LT, Eq, GT, Incomparable), which nests a 3-branch trait used for total orders 🆒

from cats.

In spirit, yes. But partial orders return a comparison wrapped in an Option, while total orders omit the Option.

Interestingly, ZIO nicely avoids an Option by using a 4-branch sealed trait (LT, Eq, GT, Incomparable), which nests a 3-branch trait used for total orders 🆒

Actually, in Cats the tryCompare method (which returns Option) is complementary. The primary one is partialCompare:

from cats.

I'm reluctant to implement a orElseOnUnrelated combinator without a clear use case.

Agree. I'm just trying to poke around different possibilities and outcomes. For example, if a method can be added to a base trait, it is usually better to add it there from the beginning even if it is not needed right away. Because if we decided to add it to the base class later, then it would be more difficult to overcome inevitable binary compatibility issues.

But when it comes to orElseOnUnrelated, it does not seem to be the case anyway – looks like it can be added later if necessary without any consequences (unless I'm missing something).

from cats.

What would be the semantics of orElse etc when two elements are not comparable on the primary PartialOrder? ie tryCompare returns None. presumably theres no delegation for consistency. The name orElse could lead people to think it tries another PO if the first is incomparable.

A possible fix for this provides a nice parallel with the existing method: name it whenEqual and expose it on the instance rather than the companion object.

This seems to imply fallbacks in any ambiguous case (equal or incomparable):

PartialOrdering
  .by[Single, VPNTier](_.tier)
  .orElseBy(it => (it.lang1, it.lang2))
  .orElseBy(_.num)
  .orElseBy(_.postfix)

This doesn't have that connotation (at least to my reading):

PartialOrdering
  .by[Single, VPNTier](_.tier)
  .whenEqual(it => (it.lang1, it.lang2))
  .whenEqual(_.num)
  .whenEqual(_.postfix)

from cats.