The cited post[1] recommends an enum for this job, which avoids the dynamic dispatch and makes it easier to get at a specific state’s data when you have the whole machine.
- Reusing code between states.
- Making callbacks to other APIs during state changes.
The state pattern is not considered to be idiomatic Rust, but in my experience it works better and is very flexible.
The state pattern has the downside that the type system does not enforce which state changes are allowed.
for
struct State<T> { state: T }
struct A { id: Uuid }
struct B { id: Uuid }
trait HasId {
fn id_mut(&mut self) -> &mut Uuid;
}
impl<T: HasId> for State<T> {
fn new_id(&mut self) { *self.state.id_mut() = Uuid::new_v4() }
}
generally, macros makes this kind of thing ergonomic so you can generate the trait implementations and so on. otherwise it's a lot of typing.
don't understand what you mean about making callbacks to other APIs during transitions.