Hi
Am 2026-06-22 10:42, schrieb Ilija Tovilo:
The Time\Duration class will also implement internal “comparison
handlers”, which means that direct comparisons with operators such as
< will work.
Can you explicitly spell out that this does not apply to arithmetic
operators?
Yes. I added “Other operators (such as + for addition) will not be
overloaded.”.
One thing worth specifying is how you're planning on handling the
passing of Duration objects to APIs that do not support certain
precisions. For example, PHPs sleep() is a thin wrapper around system
sleep(), which only accepts seconds. This would internally need to be
re-routed to usleep(), but even then usleep() only supports
microseconds. What happens when we pass a duration of that scale to
sleep()? Throw? Truncate? Round? (Let's disregard the existence of
nanosleep() for the sake of the argument.)
The behavior would be left up to the API in question, because it is in
the best position to determine which makes the most sense. As an
example, a function like `sleep()` cannot sleep for exact durations
anyways, because the computer might be busy running another process when
it is supposed to wake up. Here it might make sense to always round *up*
to the nearest microsecond, which would be in line with existing
expectations of sleeping for *at least* the given amount of time.
If something is fundamentally limited to a second-granularity - which I
expect to be comparatively rare nowadays - it might make sense to just
not accept a `Time\Duration` object and instead keep using a plain
integer - which still in a way be compatible with `Time\Duration` by the
developer explicitly only retrieving `$duration->seconds` and passing it
along.
In other situations throwing might be appropriate, particularly when the
`Time\Duration` is “too long” to be meaningfully handled (e.g.
`Time\Duration::fromSeconds(PHP_INT_MAX)`).
Within the internal API we plan to make it easy to turn a
`Time\Duration` object into a `struct timespec`, which is a “lossless”
conversion and thus it would immediately compatible with anything taking
a `struct timespec`.
In the future I could imagine a userland method that takes a
`RoundingMode` and allow to round a Duration to millis / micros /
seconds.
I have added a short “Passing Duration objects to APIs unable to handle
nanosecond precision” section summarizing the above.
The biggest concern for me is having to instantiate an object for all
calls that take a duration, which seems like mostly unnecessary
overhead. This is partially resolvable by adding support for storing
immutable objects in shared memory, which works here because the class
is readonly.
Given the class only exposes named constructors, it should be feasible
to include a small LRU cache to efficiently handle situations like the
following:
for (;;) {
$watchers = $poll->wait(Duration::fromMilliseconds(500));
foreach ($watchers as $watcher) {
/* … */
}
}
where the same timeout is repeatedly being used. I consider this kind of
optimization to be a implementation detail that is not worth spelling
out in the RFC, but it is good that you raised it for discussion.
Best regards
Tim Düsterhus
