Closed SlappedWithSilence closed 10 months ago
A common and exhausting pattern in FiniteStateDevices is creating one state that does nothing but handle branching into other states.
FiniteStateDevice
For example:
some_branching_options = { "State A": self.States.A, "State B": self.States.B } @FiniteStateDevice.state_logic(self, self.States.GO_TO_OTHER_STATE, input_type.INT, input_min=0, input_max=len(some_branching_options) - 1) def logic(user_input: int): self.set_state(self.some_branching_options(list(self.some_branching_options)[user_input]) @FiniteStateDevice.state_content(self, self.States.GO_TO_OTHER_STATE def content() return ComponentFactory.get("Some Prompt", [ [s] for s in self.some_branching_options.keys()])
Frankly, this pattern is terrible. It could be condensed into a pre-built construct that handles all this setup:
@FiniteStateDevice.branching_state(self, self.branching_state_map, prompt)
Thus, all of the branching logic can be hid from the developer.
Further, several optional arguments can be baked in, such as back_out_state to allow the user to use -1 to return to a previous state, etc.
back_out_state
-1
A common and exhausting pattern in
FiniteStateDevice
s is creating one state that does nothing but handle branching into other states.For example:
Frankly, this pattern is terrible. It could be condensed into a pre-built construct that handles all this setup:
@FiniteStateDevice.branching_state(self, self.branching_state_map, prompt)
Thus, all of the branching logic can be hid from the developer.
Further, several optional arguments can be baked in, such as
back_out_state
to allow the user to use-1
to return to a previous state, etc.