Add GenTemporal#cachedRealTime - #2941
Conversation
This method provides a nested effect which calculates time using a cached offset and `monotonic`. This is much faster than calling `realTime` repeatedly and is useful for some applications where precise time is not required
|
As described in the discussion in #2416 , and in particular this comment. |
|
@djspiewak & @armanbilge , would you mind taking a look. It seems messy to me but I'm not sure how to clean it up. Suggestions welcome. |
djspiewak
left a comment
There was a problem hiding this comment.
Doesn't seem too messy to me. :-) It's a surprisingly involved effect. The big thing that would clean it up is just leveraging the syntax.
Co-authored-by: Daniel Spiewak <djspiewak@gmail.com>
Co-authored-by: Daniel Spiewak <djspiewak@gmail.com>
|
Thanks for the feedback @djspiewak 🙂 Changes pushed. |
djspiewak
left a comment
There was a problem hiding this comment.
Really minor required change and some stylistic nits, but this is looking very good!
Co-authored-by: Daniel Spiewak <djspiewak@gmail.com>
|
Thanks again for the feedback @djspiewak . I will start using |
|
Reopening to get a new merge commit for CI |
| } | ||
| else | ||
| pure(timeNow + offset) | ||
| } |
There was a problem hiding this comment.
It could be but we tend to avoid them in most places since their desugaring is both unintuitive (creating an extra map in most cases) and not the same across Scala 2 and 3 (due to our use of a compiler plugin on the former). Perhaps more relevantly though, I don't think a for-comprehension would help much here with readability, since you would still have the testing due to the F[F[FiniteDuration]] result type.
This method provides a nested effect which calculates time using a cached offset and
monotonic. This is much faster than callingrealTimerepeatedly and is useful for some applications where precise time is not required