"In Go parlance, if each of my states has a method with its receiver set to the state type, then I can only access that data, so for example I'd need to pass something in or out to handle state transitions."
I am not clear what you mean by that, exactly, but generally I model a state machine as a type that composes a state:
type State interface {
isState()
}
// a whole bunch of state types here
type StateMachine struct {
State // exported or not exported, depending on local needs
// additional data
}
func (sm *StateMachine) Event1(args...) error {
// can call current state and change it here
}
You can add an "Execute" method on to the State and have it return an entire state if that's how you want to do it. The state machine can pass in any cross-state data. There's a number of options. You aren't obligated to do exactly, only, and precisely what you'd do in another language, and program X in Y. For some reason, that's common wisdom in the programming world... except for functional programming. I say "don't program X in Y" is simply true and there is no carveout for functional programming in non-FP languages any more than there is the other way around for OO in FP languages.
I am not clear what you mean by that, exactly, but generally I model a state machine as a type that composes a state:
You can add an "Execute" method on to the State and have it return an entire state if that's how you want to do it. The state machine can pass in any cross-state data. There's a number of options. You aren't obligated to do exactly, only, and precisely what you'd do in another language, and program X in Y. For some reason, that's common wisdom in the programming world... except for functional programming. I say "don't program X in Y" is simply true and there is no carveout for functional programming in non-FP languages any more than there is the other way around for OO in FP languages.