Closed dkumsh closed 1 month ago
The reorder sounds reasonable to me. They're pretty fresh freatures so I don't think anyone would be relying on the exact ordering yet personally.
Sounds good, I will add it to my active PR.
Pushed to the active PR
Hi, this feature has been recently added and I wanted to discuss it:
The current code base implements the following order for transitioning from State1 to State2:
I think this order should be changed to the following for better consistency and integrity:
Here are my points to support this:
The on_exit is the hook of Current State. It is responsible for finalisation tasks before leaving the current state. It must operate while the state machine is still in the the current state
Action is what the state change starts from. It can potentially modify the extended state, towards transitioning. After action is complete the state machine is half way in the transition. It's already not in Current State (as its changed the extended state) and isn't yet in New State (it has not yet assigned the new state to self.state ). The update of the state machine's internal state, completes the transition.
The on_entry is the hook of New State is responsible for initialisation tasks for the new state. These tasks must be performed after the state machine has transitioned to the new state.
Integrity consideration: If the state machine were to execute the transition action before the on_exit of the current state, it could lead to inconsistencies. For example, an action may return an error. That means that the state machine is not going to leave the current state, hence invoking on_exit in this situation is inconsistent with the definition of on_exit. Another example, resources that should be cleaned up in the on_exit might still be in use during the transition action, leading to potential errors or undefined behaviour.