3 ms·
> cumulative running time is not needed to calculate when next to call the interval I don't see how that solves anything, you are just defining a new limit to
by tomxor 8y ago
> cumulative running time is not needed to calculate when next to call the interval
I don't see how that solves anything, you are just defining a new limit to be broken, which would occur when the timer resolution is next increased if not in practice.
It makes sense that either the actual interval or timeout periods are limited by the underlying types used to store them... but I see no intrinsic reason why cumulative time that setInterval runs need be limited by any underlying type (cumulative running time is not needed to calculate when next to call the interval).
- baybal2 8y ago>I don't see how that solves anything, you are just defining a new limit to be broken, which would occur when the timer resolution is next increased if not in practice. I think that having some uniformity in a zoo of rolloverable values will make life easier to people who don't read the language spec meticulously to the letter. And yes, by any extend of human imagination, no programming language can justify implemention of a plain periodic timer through (oldTime - nowTime) % interval. A timer should be a timer, and modern opetating sysyems provide developers with a whole arsenal of high level timer abstractions just for those people to not to write their own hacks.