You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today you can do machine.state(initial=True) to mark the initial state of a machine. In tinkering with automat today, I've got a machine that has some explicit end states, and it occurred to me that it'd be nice to be able to mark them as machine.state(terminal=True) and then if you try to do .upon(some_action, ...) on them, they'd explode with an error about trying to leave a terminal state.
The text was updated successfully, but these errors were encountered:
This is a somewhat intentional design choice, although I'd definitely be OK with revisiting it.
The idea is: initial=True is necessary so that we can know what state that the machine begins in. However, the only thing that makes a terminal state "terminal" is that there are no edges that exit from it.
What is the motivation for wanting to prevent calls to .upon?
Mostly preventing errors where I know I can be explicit. I'm working on an API where users will be interested mostly in the final states. I'll try and figure out how to explain this desire more clearly. It just feels weirdly asymmetric that initial states are declared but you can't declare terminal states explicitly even if you want to, it just has to be implicit from the available transitions.
Today you can do
machine.state(initial=True)
to mark the initial state of a machine. In tinkering with automat today, I've got a machine that has some explicit end states, and it occurred to me that it'd be nice to be able to mark them asmachine.state(terminal=True)
and then if you try to do.upon(some_action, ...)
on them, they'd explode with an error about trying to leave a terminal state.The text was updated successfully, but these errors were encountered: