Why doesn't reset() reset tick to 0?

[jcmtyler]

Why wouldn't the reset() method reset the tick counter to 0?

[mateusfccp]

The semantic of the method reset is that the timer, i.e. the time left to execute the callback, is reset.

tick is the number of times duration has passed.

They are distinct.

What is your use case, and why must you reset the tick? We could find a good way to allow the user to do it, but I don't know if this is a good idea.

[jcmtyler]

Ahhh, ok that's not what I was expecting. I was hoping I could use a single PausableTimer instance repeatedly and just reset() every once in a while when I need to start the timer over, which would then reset the number of ticks. But from what you're saying it sounds like it would be better to create a new instance every time I want to reset the overall tick count.

My use case is that I have a timer that the user can reset whenever they want, and I have a max period where the timeout would expire no matter what. If max period = 60 seconds, and I start the timer with a duration of 5 seconds and let it run for 4 ticks, that would be a total of 20 seconds elapsed. If the user then resets the timer, it should go back to total elapsed of 0, so when they start the timer again, each tick would add 5 seconds to the total. When I try to do this with PausableTimer, I have to ignore the tick count because that will keep increasing even after I reset the timer.

I had initially tried the standard Timer from dart:async, but ran into issues with multiple threads accessing the timer. I was thinking if I used PausableTimer instead and made it final, it would be easier to manage across threads.

[llucax]

I think resetting the tick is a reasonable request, providing the amount of ticks it not really necessary for the implementation and was provided only to match the official Timer. Since you can increment how many counters you like in the callback itself, this feature is not necessarily needed. I agree that maybe it made more sense to reset the ticks too with reset(), but now it would be a breaking change. We could add a new optional flag, like reset(keep_ticks=false)) to reset the ticks now, I guess.

[mateusfccp]

@llucax I don't even know if our tick implementation is right. From the Timer documentation:

The tick count reflects the number of durations that have passed and not the number of callback invocations that have happened.

The example it gives is even more elusive:

final stopwatch = Stopwatch()..start();
Timer.periodic(const Duration(seconds: 1), (timer) {
  print(timer.tick);
  if (timer.tick == 1) {
    while (stopwatch.elapsedMilliseconds < 4500) {
      // Run uninterrupted for another 3.5 seconds!
      // The latest due tick after that is the 4-second tick.
    }
  } else {
    timer.cancel();
  }
});
// Outputs:
// 1
// 4

I think we do exactly what it says it shouldn't do.

[llucax]

Whoops. It doesn't sound all that useful, that's some sort of stopwatch. Maybe another reason to remove it.

[mateusfccp]

We can't remove unless we want to not implement Timer anymore. I think we should fix the behavior to be as described by the Timer interface instead.

This is something that can't be guaranteed by the type system and the interface, so we overlooked this interface requirement. We can only check for this through unit tests.

I checked manually (I had to pass the timer in the periodic constructor callback to run the exact same test) and it prints 1 and 2.

This is definitely a breaking change, so we may want to release a new major version. We may take the opportunity to introduce other breaking changes.