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 {C,c}omparison to Order, fixes #1101 #1102

Merged
merged 3 commits into from
Jun 9, 2016
Merged

Conversation

adelbertc
Copy link
Contributor

@adelbertc adelbertc commented Jun 9, 2016

Review by @non and @johnynek

@adelbertc adelbertc changed the title Add {C,c}omparison to Order, fixed #1101 Add {C,c}omparison to Order, fixes #1101 Jun 9, 2016
def comparison(x: A, y: A): Comparison = {
val r = compare(x, y)
if (r > 0) Comparison.GreaterThan
else if (r == 0) Comparison.EqualTo
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is it OK we're using == instead of Eq[Int] ? I figure it's more performant but maybe not?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, when working with a known primitive (e.g. Int) using == is correct.

Copy link
Contributor

@non non Jun 9, 2016

Choose a reason for hiding this comment

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

I agree with @ceedubs that this should probably use Comparison.fromInt(compare(x, y)) (and that the code here should be moved to Comparison).

@non
Copy link
Contributor

non commented Jun 9, 2016

If we're going to do this, we should also create a PartialComparison object which parallels this but for partial orders. For extra credit, make PartialComparison and Comparison share LessThan, EqualTo, and GreaterThan, but give partial orders an additional IncomparableTo.

@ceedubs
Copy link
Contributor

ceedubs commented Jun 9, 2016

@non would it make sense to have a partialComparison method that just returns Option[Comparison] instead of creating a separate IncomparableTo type?

@non
Copy link
Contributor

non commented Jun 9, 2016

Yeah, returning Option[Comparison] is fine too.

@johnynek
Copy link
Contributor

johnynek commented Jun 9, 2016

I like Option[Comparison] but I would allocate the values (other than None) once.

case Comparison.GreaterThan => 1
case Comparison.EqualTo => 0
case Comparison.LessThan => -1
}
Copy link
Contributor

Choose a reason for hiding this comment

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

out of curiosity, @non, do you know it the above is faster or:

sealed abstract class Comparison(val toInt)
case object GreaterThan extends Comparison(1)
case object EqualTo extends Comparison(0)
case object LessThan extends Comparison(-1)

It seems to me the above would be.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah I think having Comparison instances "know" their integer value (either through fields or through methods on the subtype) would be better than using pattern matching in .toInt.

Copy link
Contributor

Choose a reason for hiding this comment

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

It may be different with a val like that, but fwiw, at one point I benchmarked having scalaz's Maybe implement fold via pattern-matching in the parent vs dynamic dispatch to the child implementation and the former seemed to have a slight edge. It may be worth throwing together a benchmark if this is something that we care about. (I'm okay with it not being something that we care about, since people can always use the Int version of compare if they really want performance.)

@codecov-io
Copy link

codecov-io commented Jun 9, 2016

Current coverage is 88.62%

Merging #1102 into master will decrease coverage by 0.30%

  1. 10 files (not in diff) in ...cala/cats/kernel/std were modified. more
    • Misses +1
    • Hits -1
  2. 5 files (not in diff) in ...in/scala/cats/kernel were modified. more
    • Misses -1
    • Hits +1
  3. 5 files (not in diff) in ...in/scala/cats/syntax were modified. more
  4. 2 files (not in diff) in .../main/scala/cats/std were modified. more
  5. 3 files (not in diff) in ...main/scala/cats/data were modified. more
    • Misses +1
    • Hits -1
  6. 5 files (not in diff) in .../src/main/scala/cats were modified. more
    • Misses +11
    • Hits +3
@@             master      #1102   diff @@
==========================================
  Files           226        227     +1   
  Lines          2917       2944    +27   
  Methods        2867       2884    +17   
  Messages          0          0          
  Branches         48         57     +9   
==========================================
+ Hits           2594       2609    +15   
- Misses          323        335    +12   
  Partials          0          0          

Sunburst

Powered by Codecov. Last updated by 88cbe95...50da459

@non
Copy link
Contributor

non commented Jun 9, 2016

Looks great! Thanks so much. 👍

@ceedubs
Copy link
Contributor

ceedubs commented Jun 9, 2016

Nice! Thanks @adelbertc.

@non
Copy link
Contributor

non commented Jun 9, 2016

@ceedubs is that a +1 ?

@ceedubs
Copy link
Contributor

ceedubs commented Jun 9, 2016

@non yep 👍 when the build succeeds.

@non non merged commit 5cf9da3 into typelevel:master Jun 9, 2016
@non non removed the in progress label Jun 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants