-
-
Notifications
You must be signed in to change notification settings - Fork 64
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
Conditional State Transitions? #72
Comments
Thanks @colemand77, that is a great reference document for us to look at! |
In a word: no. Conditional transitions would compromise the purity of the machine, and make it more difficult to reason about what it takes to reach a particular state, which would obviate much of the usefulness of being able to diagram the machine automatically et cetera. But, obviously we need some way to handle the case that you've brought up. This is, in my mind, yet another use-case for #41 . |
The way to implement this within the scope of Automat's design would be for the Does this make sense to you as a solution? |
Yep, totally. The "no |
Another use case for this kind of logic is a retry loop, where you want to retry something up to N times until you get a success. It is possible to represent both of these use cases as a state machine, but you need N copies of each of the states involved in processing a submission. This is similar to the |
The way to implement this sort of transition is now explicitly covered in the tutorial, under this exact heading: https://automat.readthedocs.io/en/latest/tutorial.html#conditional-state-transitions Hope that this fixes the problem, sorry you had to wait 7 years :) |
Fully recognize this question may reflect bad practice or might just run counter to the opinion of the framework (which is great!), but do you have any plan to implement conditional state transitions?
Borrowing from your example, if the coffee maker needs, say, '5 beans' in order to brew coffee, is there any way (within the framework) to check that condition is satisfied, or would something like the following be the 'automatic' way to implement that? (pythonic -> automat-ic? get it?)
I don't have any ideas or thoughts about how an alternative method would be implemented, or whether it even belongs. The reason I'm asking is that I see what could end up being a lot of state-checking and perhaps a lot of branching logic outside of the automat framework -> and maybe thats ok? Just making sure I'm not missing something.
As an aside: I'm working through this document: and trying to learn automat by implementing the examples; which is helpful in terms of thinking about setting up more complicated machines from primitives (cascading, parallel, etc), but their implementation philosophy is so different... if I can grok it, it might make for some helpful documentation additions.
The text was updated successfully, but these errors were encountered: