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

Add comparison method in Order companion object #2100

Merged
merged 2 commits into from
Dec 17, 2017

Conversation

ceedubs
Copy link
Contributor

@ceedubs ceedubs commented Dec 13, 2017

The main goal of this PR was to add syntax tests for the Order and
PartialOrder syntax (provided via machinist ops) to address this comment.

In the process I noticed that the Order companion object didn't have a
comparison function to forward through to the type class instance like
it did for other methods, so I added that.

I did notice that the Order/PartialOrder syntax does work whether or
not you take the Order/PartialOrder instances as implicit parameters
to the ops classes. I think that only @non understands quite what's
going on with the machinist syntax macros, so I didn't make the changes
to take away those implicit parameters without knowing the implications.
The tests pass either way, so I think that end-code should work for
users either way.

The main goal of this PR was to add syntax for the `Order` and
`PartialOrder` syntax (provided via machinist ops) to address [this comment](typelevel#1867 (comment)).

In the process I noticed that the Order companion object didn't have a
`comparison` function to forward through to the type class instance like
it did for other methods, so I added that.

I did notice that the `Order`/`PartialOrder` syntax does work whether or
not you take the `Order`/`PartialOrder` instances as implicit parameters
to the ops classes. I think that only @non understands quite what's
going on with the machinist syntax macros, so I didn't make the changes
to take away those implicit parameters without knowing the implications.
The tests pass either way, so I think that end-code should work for
users either way.
@ceedubs
Copy link
Contributor Author

ceedubs commented Dec 13, 2017

Tests passed locally, but during the build one failed with Message: NaN did not equal NaN 🤦‍♂️.

I'll come up with a workaround.

@codecov-io
Copy link

codecov-io commented Dec 13, 2017

Codecov Report

Merging #2100 into master will increase coverage by 0.13%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2100      +/-   ##
==========================================
+ Coverage   94.66%   94.79%   +0.13%     
==========================================
  Files         322      322              
  Lines        5451     5455       +4     
  Branches      215      216       +1     
==========================================
+ Hits         5160     5171      +11     
+ Misses        291      284       -7
Impacted Files Coverage Δ
kernel/src/main/scala/cats/kernel/Order.scala 89.18% <100%> (+5.85%) ⬆️
core/src/main/scala/cats/instances/tuple.scala 100% <0%> (ø) ⬆️
.../main/scala/cats/laws/CommutativeFlatMapLaws.scala 100% <0%> (+33.33%) ⬆️
...cats/laws/discipline/CommutativeFlatMapTests.scala 100% <0%> (+50%) ⬆️

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 275f723...a225223. Read the comment docs.

@LukaJCB LukaJCB merged commit dda5df3 into typelevel:master Dec 17, 2017
@stew stew removed the in progress label Dec 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants