Closed bgourlie closed 4 years ago
Do you see any problems having a context this way rather than the way I put it?
No, but being a proof-of-concept I haven't thought through the idea entirely. I think it's fine for guard functions, but for action functions I have a few questions about how they would be used in practice (which actually apply to the current implementation as well).
Also, do you see a way to have a default context if there is none supplied?
In a situation where no guard/action methods are specified in the DSL, the macro could emit an implementation of the context trait over an empty tuple. The user wouldn't have to specify their own context type and would (in its current form) do something like StateMachine::<()>::new()
, however I'm sure there would be a way to avoid a type parameter entirely.
I don't have a good solution for when they supply actions/guards but no context. Having something to contain the state machine-specific functions seems nice to me though, instead of the functions just being expected to exist in the current scope.
As it relates to action functions, it seems in order to do anything useful they would actually need to take &mut self
. In their current form (sans this PR), it seems like they would need to modify static mutable data (for example, to poke at hardware registers if this were an embedded application.) I may be missing something obvious here though :)
I plan on trying out some ideas in this PR as time permits (I'm pretty busy this week) and try to integrate it in some sort of practical application. I have a little demo game I've built where I implemented a state machine by hand, which would be a good place to put it to the test!
Hi again, sorry for letting this go for so long. I will merge this as is, and continue based on this idea! Thanks for fixing it!
Possible solution to #2
This is a proof of concept solution for having guard/transition methods have access to some user-defined context. At a high level, all guard/action methods get placed into a context trait (currently hardcoded as
StateMachineContext
) which the user would implement on their own type.