Having done quite some FSM-based programming, I completely understand and appreciate the value of Typestate! While getting it correct requires time and effort ( _con_ , some may say ), prevention of wrong APIs being called by the compiler, carries immense value ( the obvious _pro_ ). Thank you for a concise presentation, Stefan!
What if the build is available when set mutiple things need to be set, I guess you might have to use a bitset to decide if all things are set or not? Is there any better way?
The other variant of this I have seen uses PhantomData and a typestate struct like here, rather than using the typestate as the type of the missing data. I think I like the version presented here, which does not need PhantomData to implement. I wonder if there is some more subtle difference?
I wonder how this generics approach works under the hood... specifically, does it do a copy on each state transition. I imagine maybe the PhantomData approach does not cause a copy on a state transition.
I think the difference is that if you do use phantomdata, you can't store any data in whatever you are gentrifying over. In this example we say that workload is of type W which we then directly use in the build method with workload.into(). This means that it is not actually a zero sized type whilst if we used phantomdata, this would not be possible (as we can't store anything in it). I wouldn't consider myself anywhere near knowledgable in the language so please correct me if Im wrong :)
@@boenrobot There really should be no difference between state transition using PhantomData or Unit structs, both are zero sized. The main difference is you can go from a unit struct to a non-zero sized type and add data to the new version, you can't do that with PhantomData. I would also add that storing the generic type directly also helps with type inference. I would argue that if you have a generic struct, and you intend for that generic type to be zero sized, you shouldn't use PhantomData and just store the type directly. One more thing is it should be the last field of a struct, this prevents it affecting alignment and padding of the rest of the fields, and allows unsizing.
Thanks for the vid. I'd be curious if anyone might remark on these things: * I remember a criticism of "patterns" is that may indicate a deficit in language constructs, or maybe the wrong tool for the job -- it makes me wonder how else this problem could be solved, e.g. with some kind of imperative programming. * Could this pattern heighten the stack in an undesirable way? * Is this what the Warp library is doing with it's Boxy filter chains?
Thanks for sharing this insight using typestate with the builder pattern. It sends very useful. One thing I wonder about is how would this scale when multiple required properties need to be set. I have to expect that either the required properties would have to be set in a specific order or that there would be an explosion of possible typestates. Is there another elegant solution that would deal well with that scenario?
If multiple properties are *required* then I think (maybe) you could simply keep the final state as a separate typestate. I don't think the intermediate (incomplete) states are so important here, but I am not adept at using the typestate pattern yet so maybe I'm wildly off-base.
Really nice explanation! I'm a big fan of this pattern makes the code really easy to understand and work with!
the code demonstration at the end with neovim (nice setup!) really nailed it! Things became very clear
Having done quite some FSM-based programming, I completely understand and appreciate the value of Typestate! While getting it correct requires time and effort ( _con_ , some may say ), prevention of wrong APIs being called by the compiler, carries immense value ( the obvious _pro_ ). Thank you for a concise presentation, Stefan!
This was really interesting! It was especially satisfying seeing the types change to reflect state based on previous calls. Thank you!
18:45 => Typestate Programming "chapter"
What if the build is available when set mutiple things need to be set, I guess you might have to use a bitset to decide if all things are set or not? Is there any better way?
Ahh yes, the Design Patterns book
Wow! So compiler will not let you forget to pass a workload to construct a worker!
small typo at 9:50:
.uri("...");
.header("...", "...");
there shouldnt be a semicolon after the .uri()
This is really confusing at first but very insightful at the end.
The other variant of this I have seen uses PhantomData and a typestate struct like here, rather than using the typestate as the type of the missing data. I think I like the version presented here, which does not need PhantomData to implement. I wonder if there is some more subtle difference?
I wonder how this generics approach works under the hood... specifically, does it do a copy on each state transition.
I imagine maybe the PhantomData approach does not cause a copy on a state transition.
I think the difference is that if you do use phantomdata, you can't store any data in whatever you are gentrifying over. In this example we say that workload is of type W which we then directly use in the build method with workload.into(). This means that it is not actually a zero sized type whilst if we used phantomdata, this would not be possible (as we can't store anything in it).
I wouldn't consider myself anywhere near knowledgable in the language so please correct me if Im wrong :)
@@boenrobot There really should be no difference between state transition using PhantomData or Unit structs, both are zero sized. The main difference is you can go from a unit struct to a non-zero sized type and add data to the new version, you can't do that with PhantomData. I would also add that storing the generic type directly also helps with type inference. I would argue that if you have a generic struct, and you intend for that generic type to be zero sized, you shouldn't use PhantomData and just store the type directly. One more thing is it should be the last field of a struct, this prevents it affecting alignment and padding of the rest of the fields, and allows unsizing.
Thanks for the vid. I'd be curious if anyone might remark on these things:
* I remember a criticism of "patterns" is that may indicate a deficit in language constructs, or maybe the wrong tool for the job -- it makes me wonder how else this problem could be solved, e.g. with some kind of imperative programming.
* Could this pattern heighten the stack in an undesirable way?
* Is this what the Warp library is doing with it's Boxy filter chains?
Thanks for sharing this insight using typestate with the builder pattern. It sends very useful.
One thing I wonder about is how would this scale when multiple required properties need to be set. I have to expect that either the required properties would have to be set in a specific order or that there would be an explosion of possible typestates. Is there another elegant solution that would deal well with that scenario?
If multiple properties are *required* then I think (maybe) you could simply keep the final state as a separate typestate. I don't think the intermediate (incomplete) states are so important here, but I am not adept at using the typestate pattern yet so maybe I'm wildly off-base.
Feels like someone could create a macro for this that boils it down to a single python-like constructor.
Enums instead of generics?!!
Are named arguments abandoned forever? 😢