Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@adrianfilip
Copy link
Contributor

Used the suggestions from:

There were minor test changes where tests relied on types.
Also because duration is now a java.time.Duration Duration.fromNanos(Long.MaxValue) will equal Duration.Infinity.

@adrianfilip
Copy link
Contributor Author

cc @adamgfraser @jdegoes

@adrianfilip adrianfilip changed the title 3685: zio duration uses java.time.Duation 3685: zio duration uses java.time.Duration Aug 1, 2020
Copy link
Contributor

@adamgfraser adamgfraser left a comment

Choose a reason for hiding this comment

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

This looks really good! Great to see so few changes in the rest of the code base.

I think at this point there are only a few user facing differences:

  1. Because Finite is not a subtype of Duration anymore but just an extractor, when pattern matching users need to do case Finite(duration) => ??? rather than duration: Finite => ???. I think this is unavoidable with the new encoding and relatively minor.
  2. Because Duration is no longer our data type, we have to add methods like > with extension methods. That means if you just have a Duration instance you can't call > on it without doing something to bring the implicit syntax into scope. So right now the user needs to do import zio.duration._. We could potentially either move this into the ZIO package object so it is in scope with import zio._ or use the trick where we give the implicit conversion the name of the type (implicit def Duration(duration: Duration): DurationOps = new DurationOps) so it is in scope when the user does import zio.Duration but unfortunately I don't think any of these are ideal as a lot of times you will just have a Duration value from some combinator you are working with.

One other thing that could be good to do here is define an Ordering[Duration]. We had Duration extend Ordered[Duration] before but now we can't do that since it isn't our own data type.


def apply(amount: Long, unit: TimeUnit): Duration = fromNanos(unit.toNanos(amount))

def fromNanos(nanos: Long): Duration = nanos.nanos
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
def fromNanos(nanos: Long): Duration = nanos.nanos
def fromNanos(nanos: Long): Duration = Finite(nanos)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did not use Finite because if we pass a Long.MaxValue it will result in an Infinite.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also all constructors (.nanos, .millis, ...) build Duration.Zero if given negative values.

@jdegoes
Copy link
Member

jdegoes commented Aug 1, 2020

We could consider using a super lightweight "newtype" encoding to present our Duration as a subtype of Java Duration, if we didn't want the user to have to import syntax.

Albeit, I think it's common to do import zio.duration._. At least, that's what I always do.

@jdegoes
Copy link
Member

jdegoes commented Aug 3, 2020

@adrianfilip Can you resolve conflicts so we can merge?

@adrianfilip
Copy link
Contributor Author

Yes.

@adrianfilip
Copy link
Contributor Author

Done

@jdegoes
Copy link
Member

jdegoes commented Aug 3, 2020

💪

@jdegoes jdegoes merged commit 97c3be4 into zio:master Aug 3, 2020
@adrianfilip adrianfilip deleted the 3685_duration_java branch August 4, 2020 20:46
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.

3 participants