Description
scala.concurrent.duration.Deadline
So, I guess I have a few gripes about Deadline. I love using FiniteDuration, and often use it to reference times from the Unix Epoch. To distinguish between durations and my absolute times, I would usually wrap an absolute time (as a timestamp is just a duration from the unix epoch) in my own case class. I decided to switch over to Deadline because it appeared to do all this already, and because of its relation to FiniteDuration.
So, things I wanted to do with Deadline are:
*Serialize
*Convert to/from FiniteDuration from unix epoch (System.currentTimeMillis)
Currently Deadline is a case class of the FiniteDuration from 0 System.nanoTime. Nano time does not reference any global epoch, and I'm assuming it references the system uptime. Deadline is completely sealed and it does nicely hide what it’s doing internally while keeping best accuracy possible.
So, things I wish Deadline didn’t do-
*Expose the internal delta-from-0-nanotime duration (public 'time' method, and unapply on companion)
*Prevent you from constructing new Deadlines (if it’s going to give me access to the data it shouldn’t, i should be able to at least use that to create a new Deadline timer)
*Be sealed. Could possibly use some abstraction given then all Deadlines will be a FiniteDuration from some epoch (either nanoTime 0, or unix epoch… whatever)
Justifications-
*Serialization is good; when there is a globally honored reference point for time, that should be used when serializing. I like the nano time for internal, but at least mark a reference of nanoTime == timestamp or something similar so you can make a global Deadline.
*Abstraction is pretty good… I don’t think it would hurt at all to make Deadline a trait, the interface is pretty simple on it. Could also allow users to use different resolutions for timers without having to change middle code (or destroying performance if your system is slow with nanoTime). One could even make a deadline timer for games that respected game pauses!
*Deprecation - The only thing that could be fixed above that would cause compatibility issues would be the unapply extractor. The ‘time’ method could get a deprecation annotation and be done with it. I don’t think anybody is extracting the existing time tho (time from local nano 0), as you can’t really do much with the end result anyways. Could also just deprecate the old extractor and create new ones for UnixEpochDeadline, and NanoTimeDeadline or etc…
I'm already starting a patch. Let me know if its not worth it, and I'll spare everybody the pull request.