3 ms·
Abstracting the email example, if you have a finite state machine that verifies some fact, you can model each state as a type. Their example goes Email -> Valid
by noelwelsh 2y ago
Abstracting the email example, if you have a finite state machine that verifies some fact, you can model each state as a type. Their example goes Email -> ValidEmail -> VerifiedEmail. You could equally go String -> Email -> VerifiedEmail, where String is what the user submits as their email address. If you are verifying emails in the context of verifying users you could go Map<String, String> -> User -> VerifiedUser, where Map<String, String> is what you receive from an HTML form submission.
Getting hung up on the details of which type you use is missing the overall point.
- atoav 2y agoGood point, the names really don't matter and the first type could as well have been a string. I just wanted to illustrate the concept of using the type system to add important information and guarantees to certain variables. Your state machine analogy is a good one, because the conversion between different types is a bit like the transitions between states: you have to make explicit how exactly they are meant to happen (or whether they are actually possible). This is a good thing, having less degrees of freedom may seem like it makes it harder to code, but in fact it allows you to reason better about what the system is doing at any given point in your code.
- bvrmn 2y agoState machine is always a trivial part. Email verification is stupidly simple task. But User propagation through the system and available actions based on verified email are not.