Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

conversion PartialOrder to PartialOrdering and Hash to Hashing #2116

Merged
merged 5 commits into from
Dec 18, 2017

Conversation

kailuowang
Copy link
Contributor

To address some items in #2093
Note that this code change is binary compatible in kernel (I tested Mima without any of the exceptions I added) but not binary compatible in core.

@kailuowang
Copy link
Contributor Author

@denisrosset , will you take a look as well?

@codecov-io
Copy link

codecov-io commented Dec 17, 2017

Codecov Report

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

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2116      +/-   ##
==========================================
+ Coverage   94.62%   94.63%   +<.01%     
==========================================
  Files         325      325              
  Lines        5511     5514       +3     
  Branches      207      213       +6     
==========================================
+ Hits         5215     5218       +3     
  Misses        296      296
Impacted Files Coverage Δ
core/src/main/scala/cats/instances/hash.scala 100% <ø> (ø) ⬆️
kernel/src/main/scala/cats/kernel/Order.scala 88.88% <ø> (-0.31%) ⬇️
...e/src/main/scala/cats/instances/partialOrder.scala 100% <ø> (ø) ⬆️
core/src/main/scala/cats/instances/eq.scala 80% <ø> (ø) ⬆️
core/src/main/scala/cats/instances/order.scala 83.33% <ø> (ø) ⬆️
...rnel/src/main/scala/cats/kernel/PartialOrder.scala 91.42% <100%> (+0.51%) ⬆️
kernel/src/main/scala/cats/kernel/Eq.scala 93.75% <100%> (ø) ⬆️
kernel/src/main/scala/cats/kernel/Hash.scala 91.66% <100%> (+1.66%) ⬆️

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 e8fb7ed...262418f. Read the comment docs.

LukaJCB
LukaJCB previously approved these changes Dec 17, 2017
Copy link
Member

@LukaJCB LukaJCB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

ceedubs
ceedubs previously approved these changes Dec 17, 2017
Copy link
Contributor

@ceedubs ceedubs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but I'd like to get input from @johnynek and/or @denisrosset

@denisrosset
Copy link
Contributor

denisrosset commented Dec 18, 2017

Why do both the core instances and the PartialOrder companion object extends the trait containing implicit conversion?

def fromPartialOrdering[A](implicit ev: PartialOrdering[A]): PartialOrder[A] = from[A] { (a, b) =>
ev.tryCompare(a, b).fold(Double.NaN)(_.toDouble)
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer extending the PartialOrder trait here instead of having so many lambdas (from and the fold).

@kailuowang kailuowang dismissed stale reviews from ceedubs and LukaJCB via 2f836a7 December 18, 2017 01:06
@kailuowang
Copy link
Contributor Author

@denisrosset the core instances extends it so that it's available through import cats.implicits._, the PartialOrder companion object extends it to maintain compatibility.

@denisrosset
Copy link
Contributor

So, if I understand correctly, the conversion will always be available regardless of the import cats.implicits._ directive?

@kailuowang
Copy link
Contributor Author

kailuowang commented Dec 18, 2017

no, it will only be available through import cats.implicits._. The one in the companion object is of little use.

Update: To be clear, the original way it was added was basically wrong - it's added as an implicit but in a companion that won't get searched.

@denisrosset
Copy link
Contributor

Update: To be clear, the original way it was added was basically wrong - it's added as an implicit but in a companion that won't get searched.

I suggest to document this, implicits are confusing enough. If you don't want to modify this PR, I'll add a comment on the Google doc and will have a pass a it later.

@denisrosset
Copy link
Contributor

denisrosset commented Dec 18, 2017

A couple of comments.

  • Eq does not have a conversion to Equiv.
  • Hash has an implicit conversion to Hashing, but a contradictory comment in the Hash typeclass itself.
  • No toHashing, toPartialOrdering, toEquiv methods.
  • The implicit conversion for Order is on instances.order, but the one for PartialOrder on instances.partialOrdering.

This is corrected by the commit:

denisrosset@2b0a67f

@LukaJCB
Copy link
Member

LukaJCB commented Dec 18, 2017

Awesome @denisrosset! Would you like to PR that to Kai's branch? :)

@kailuowang
Copy link
Contributor Author

@denisrosset I will address your feedbacks.
In regards to the toHashing, toPartialOrdering, toEquiv methods though, they will break binary compat for those type classes. If it's okay to break kernel.implicits I can add the implicits conversion traits there so that kernel users can have them through import cats.kernel.implicits._. WDYT?

@LukaJCB
Copy link
Member

LukaJCB commented Dec 18, 2017

As far as I can tell from the source, neither Algebra, nor Spire or Algebird make use of kernel.implicits.

@kailuowang
Copy link
Contributor Author

Hash#toHashing deliberately not implemented since scala.util.hashing.Hashing is only
compatible with universal equality.

This is probably a good reason for not providing any Hash to Hashing conversion, no?

@kailuowang
Copy link
Contributor Author

@denisrosset I've added the conversions to cats.kernel.instances.all so that they can be available for kernel users through reports. I removed the Hash -> Hashing conversion due to reason commented above.

@denisrosset
Copy link
Contributor

This is probably a good reason for not providing any Hash to Hashing conversion, no?

Except that the documentation for Hashing in the 2.12 api is:

Note: when using a custom Hashing, make sure to use it with the Equiv such that if any two objects are equal, then their hash codes must be equal.

@kailuowang
Copy link
Contributor Author

@denisrosset is it the same way in 2.11 and 2.10?

@denisrosset
Copy link
Contributor

@kailuowang
Copy link
Contributor Author

@denisrosset that seems right. I couldn't find from the original PR why that comment was added.
Added the Hashing conversion back.

@LukaJCB LukaJCB requested a review from ceedubs December 18, 2017 19:13
@LukaJCB LukaJCB merged commit 02b819c into typelevel:master Dec 18, 2017
@stew stew removed the in progress label Dec 18, 2017
@kailuowang kailuowang deleted the partialOrder branch December 18, 2017 21:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants