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

remove generic Timer struct's State parameter #102

Open
PTaylor-us opened this issue Apr 28, 2021 · 5 comments
Open

remove generic Timer struct's State parameter #102

PTaylor-us opened this issue Apr 28, 2021 · 5 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@PTaylor-us
Copy link
Member

Ref: #75

The State type parameter means that a Timer that is going to change state cannot be (nicely) stored in a struct.

Does the Type type parameter also block some use cases?

@PTaylor-us PTaylor-us added the enhancement New feature or request label Apr 28, 2021
@korken89
Copy link
Collaborator

korken89 commented May 4, 2021

I'll give this a look.

@korken89
Copy link
Collaborator

Hi, I have given this a look and we stand between 2 choices:

Either one has type states which is nice for compile time checking but cumbersome to use in runtime and place in structs,
or we go with the state being an enum in the timer itself which means runtime checking of states and we loose the compile time checks.

One can also wrap the timer object in an enum, where each enum variant maps to a state.
However this would be a bit weird as one turns the state problem inside out with making state explicit to the user to handle.
Eg TimerState::Running(timer), where the user has to check and do the right thing depending on the TimerState.

What are your thoughts on the @PTaylor-us ?

@PTaylor-us
Copy link
Member Author

@korken89 I think the issues brought up with the current type-state scheme are serious enough to switch over to runtime checks. I like the elegance of the type states, but it's just not a good fit for this situation. So I think storing an enum state in the timer is a good way to go.

@PTaylor-us
Copy link
Member Author

@korken89 Have you already done any work on this? I may want to work on it, but don't want to duplicate effort.

@korken89
Copy link
Collaborator

Unfortunately not, I became a dad recently so my contributions to open source projects is currently on hold for a while longer. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants