@ahmadkhattab5700
Great presentation, Alex! I really enjoy your talks, they’re always insightful. Keep up the great work!
@andreacaramagno486
Beautiful talk. Excellent explanation despite the advanced features used. Thanks a lot
@gk0io
Thanks for the talk! New concept to me, even the tools for it were available for a while. Now would be looking for an opportunity to implement it.
@MaksBarbaruk
I've already tried a little bit of Type Driven stuff, will try this as well. Love this guy
@Stricken174
Greatest explanation of consuming functions!
@azamsharp
Great talk as usual from Alex!
@ahmdmhasn
True engineering! Thank you.
@tejasfarera735
A good way to apply enforcement!
@filipp7611
Very cool, will use it for sure.
@AlvarHansen
Amazing talk! I finally got it where borrowing can become useful.
@vincentcifello4435
Another great talk Alex. Seems like the OOP/polymorphism is really the root of the problem. This works, but…the word shoehorned comes to mind. A function SwitchToDrive that only accepts a ParkedCar and returns a DrivingCar is likely a better overall approach. What do you think? I believe you talk about this in your Swiftology blog. Please add more articles!
@PavloMoroz-p9w
Good stuff!!!! Thanks a lot!
@alexanderbugara5432
Alex thank you for this amazing talk. I got something new. Only one place I didn't get is 28 min definition of polymorphism. May be It was about polymorph on types, I am not sure. Thanks.
@evangelosspyromilios5994
Amazing talk, thank you so much dude
@barco-a-la-deriva-a
Thank you, Alex! It's a great talk. But I would like to share a few thoughts, and I would be interested to hear what you think about this. At first, I really liked the concept that we can't even compile incorrect logic by calling an unsupported method in a certain state, but then I started thinking. 1) In another talk, 'Type Driven Design,' you mentioned other techniques (such as the Witness pattern etc.), and you mentioned that the goal of all of this is to reduce the chance that an error will sneak into the code (it’s much easier to spot during a code review), but it’s not 100% guarantee. For example, we can always cache the witness object and call the corresponding method 'at the wrong time.' But to do this, we would need to explicitly 'break' the code, which makes it practically impossible to do by accident. In the case of the Typestate pattern, don't you think it's just as easy to make a mistake and accidentally add a method to a certain state, especially since we have to write quite a bit of boilerplate code, and I imagine we might sometimes copy-paste code blocks and accidentally add a method to the wrong state? It seems to me that such an error would be easier to overlook, and the whole benefit of this approach would be lost. Moreover, we’d end up writing a lot of extra code. 2) In the case of a regular state machine (State pattern or some other implementation), we can cover the code with tests, meaning an error will only reach the code if the test also has an error. In the case of the Typestate approach, we won’t have a test for an 'incorrect' call because the compiler won’t let us compile the test. So, if someone later accidentally adds an 'incorrect' method to a certain state, we won’t be able to catch this with tests. In any case, thank you very much for the talk. It was very interesting and insightful. I didn’t even know about such possibilities in the latest versions of Swift.
@gordonprice695
Nice Vyshyvanka. Slava Ukraini. Now on to the video. :)
@glebcherkashyn2357
I wonder if this approach affects app's performance, and if it does - how exactly
@isiyerm
Nice talk, Alex! Thank you! I have a few questions and would love to hear your thoughts: 1. Will this approach work when we have a nested state machine? Example: Suppose we have a hierarchical state like Authenticating -> WaitingForOTP -> Verified, and Authenticating itself is also a state machine. Does this mean we would need to create multiple methods to handle not only parent state transitions but also all possible transitions for child states? Would this significantly increase complexity as the number of nested states grows? 2. Is this approach applicable to collections? Let’s imagine I have a Task state machine and would like to store multiple tasks(Task<Pending>, Task<Running>, Task<Completed>) in an array. If each task follows a strict Typestate model, how would we store multiple tasks in different states within a single collection?
@clementdato6328
It does feel like the last Enum class nullify previous effort, even though there is indeed difference.
@RustIsWinning