add Comparison to cats package

[kailuowang]

fixes #2109

[codecov-io]

Codecov Report

Merging #2110 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2110      +/-   ##
==========================================
+ Coverage   94.79%   94.79%   +<.01%     
==========================================
  Files         325      325              
  Lines        5494     5495       +1     
  Branches      219      218       -1     
==========================================
+ Hits         5208     5209       +1     
  Misses        286      286

Impacted Files	Coverage Δ
core/src/main/scala/cats/package.scala	100% <100%> (ø)	⬆️

---

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 5234312...3b21ad6. Read the comment docs.

[iravid]

Thanks @kailuowang! Should the type be exported as well?

[johnynek]

do we not need the type Comparison?

[kailuowang]

I don't see much of the benefit of aliasing Comparison type. Unlike existing aliases, it's not a type class. The original request in #2109 is to do pattern match on comparison without an extra import, the current change should suffice for that requirement right?

a comparison b match {
   case Comparison.GreaterThan => ...
   ...
}

Of course if we want to pass the comparison result around we would need the type, but how often is that? I was just trying to do the minimum (and minimize namespace pollution) to satisfy the original request.

[johnynek]

I think it is inconsistent to be able to do def getEq: cats.kernel.Comparison = Comparison.Equal why does one have the kernel, but not the other?

[iravid]

For pattern matching accessing the data constructors is indeed sufficient. I don’t have a concrete usecase for passing around a comparison currently but it looks inconsistent with the rest of the kernel re-exports.

Namespace Pollution is an interesting consideration but I’m not familiar with the trade offs here. My desire is to stick with the cats, cats.data and cats.implicits imports :-)

[kailuowang]

Consistency is a good argument. I added the type.

[iravid]

Thanks again!

[LukaJCB]

👍