| |
| ▲ | gardaani a day ago | parent | next [-] | | The article also mentions that typestates can be cumbersome: > Typestate improves code faultlessness and testability, but comes at the cost of more boilerplate code and can degrade readability. I have noticed this in my own code. `Ticket` with an internal variable tracking the state makes using it simpler. I just have to store one object in my struct `struct MyData { ticket: Ticket }` and call `ticket` methods in the correct order. Typestate `Ticket<T>` is not as simple. I have to wrap it in my own enum: `enum TicketState { Ticket1(Ticket<Func1Done>), Ticket2(Ticket<Func2Done>), }` to store in my struct: `struct MyData { ticket: TicketState }`. Then every time I call `ticket` methods, I must extract the correct variant value first. That degrades readability and creates extra run-time cost. | | |
| ▲ | vatsachak a day ago | parent [-] | | You don't need the enum? You just require Ticket<T_0> as a function argument. It's really not that cumbersome, it's like two extra lines of code... |
| |
| ▲ | throwaway894345 a day ago | parent | prev [-] | | I’m probably doing it wrong, but when there’s a state with multiple transitions out, I can either model it as distinct methods per transition in which case the caller needs to know how to transition between states or I can have the caller pass an enum in which moves the branch into the state machine at the expense of an enum and a match statement. It’s also like 10x the code. Again, I’m very open to the possibility that I’m doing something wrong. Curious how you would model a state machine for (1) reserving the right to do the inventory (2) querying the next page of results (based on a cursor) and (3) recording the page information and the next cursor. | | |
| ▲ | vatsachak a day ago | parent [-] | | In the type state pattern you would have something like this pub trait ValidState {} struct StateMachine<'a, T> where T: ValidState
{untyped: &'a mut
UntypedStateMachine, _marker: PhantomData<T> } fn reserve_right<'a>(state: StateMachine<'a, Begin>) -> StateMachine<'a, Reserved> fn query<'a>(state: StateMachine<'a, Reserved>) -> StateMachine<'a, Queried> fn record<'a>(state: StateMachine<'a, Queried>) -> StateMachine<'a, Recorded> | | |
| ▲ | throwaway894345 14 hours ago | parent [-] | | How do you model cases where the reservation fails, where the inventory operation is already complete, etc? Basically conditional transitions based on some data received? Also, where does the actual I/O happen? Presumably there is some shell that drives the state machine that does the I/O before or after executing the transition? | | |
| ▲ | vatsachak 12 hours ago | parent [-] | | The I/O is done using the mutable reference to the UntypedStateMachine in the functions. For example UntypedStateMachine could just be a vec that you append to or read from. If you want to model cases with failure your return type will be Result<StateMachine<Reserved>, Error> A conditional transition should return something like (StateMachine<PostConditional>, ConditionalData) | | |
| ▲ | throwaway894345 an hour ago | parent [-] | | I think this makes sense. I’m eager to try it. Some residual questions: what is “untyped” in this case and what is “PostConditional” (an enum of possible states?)? How do subsequent transitions work? |
|
|
|
|
|
