Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behavior of Timeout class is not entirely intuitive #98

Open
dallmair opened this issue Dec 4, 2023 · 0 comments
Open

Behavior of Timeout class is not entirely intuitive #98

dallmair opened this issue Dec 4, 2023 · 0 comments

Comments

@dallmair
Copy link
Member

dallmair commented Dec 4, 2023

The stopped() method returns the information whether the timeout is still running or not, and it does not check for expiration. The expired() method checks for expiration, and also stops the timer, so it only returns true a single time. In a table:

Situation stopped() expired()
Stopped true false
Started, not expired yet false false
Started, expired before expired() is called: false
after expired() is called: true
true, but only once
false on second and all following calls

The current implementation is good for use cases where some code needs to be run a single time after a timeout expires. However, it's not ideal for use cases where one actually needs "delay" semantics, i.e. do nothing while the timeout is running, but always run the code after expiration.

It's not clear at the moment what the best solution is. Ideas:

  1. Change semantics of the expired() method to return true when the Timeout is stopped. Need to check all existing usages whether this is possible, and also whether it makes sense.
  2. Add a method stoppedOrExpired(), which at least shows up in IntelliSense and should make developers think.
  3. Add another class Delay that actually implements delay semantics. Could use Timeout internally.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant