So you can pipe a series of alts together to perform coalescing, eg. you have multiple possibly None values, and you want the first one that isn't None
Yep, that's right! 👍 You can have multiple alts in sequence and you will keep executing them until one of them succeeds (i.e., returns a Some) or they all fail (i.e., all return None).
[Option] is not really an error. It's an optional value. [Either] is more suitable for error handling. Option just tells you if value exists or not. In real world it would be Either
That is not accurate. Option can be used to "represent the effect of a possibly failing computation" as stated in the fp-ts documentation. In fact, in the case in which you don't care about an error message or error type and you only want to know if the computation succeeded or not, you can totally use Option. Even in other languages, like Haskell, the Maybe monad (the equivalent of Option in fp-ts) can represent the result of a computation that can fail. Also in Rust, in the std::option module docs, it states that one of the uses of Option is as "Return value for otherwise reporting simple errors, where None is returned on error."
@@MrFunctor sure you can. But its confusing when there is no context of your "error". That's why I'm saying its not really an error. Computation can fail with many reasons. For example it's not ok to return Option when you parse uuid, or divide by zero but some people do it. To summarize: technically it is "simple error" or fail. In real world you never use Option as an error
Yeah, I agree that when you have a function that may fail for different reasons, you should return an Either to be able to specify the kind of error that caused the function to fail. However, there are also cases in which you have simple functions that can fail for only one obvious reason and in those cases it makes sense to return an Option. In the video, we have getMovieAwardHighlight, which is a function that tries to get the movie.award and return an award highlight. However, if the movie has no award, this function "fails" and returns a None. So, in this case, it is clear that if you got a None, it must be because the movie has no award. The same applies to getMovieTop10Highlight: the only reason why that function may fail is because the movie is not in the top 10, so it cannot return a TOP 10 highlight, and that's why it's fine for it to return an Option.
Wonderful, thank you! Shed some light on two concepts I’ve been wanting to learn more about, namely .alt as well as W (Widen). Is that how I should think when I encounter the W in the various methods? That the return type can be different than the original? Or was that only for this specific context?
Hello Dawid! Yes, that's how you should think when you encounter methods that end in W: it just stands for Widen/Widening with the meaning that it is widening the return type. 👍 Most of the time, you don't want to unintentionally widen return types, so the default behavior tends to enforce that the return type remains the same. In a few cases, where you do need to widen the type, you have to explicitly call the W variant of a particular method.
Remember that fold is just an alias for match, which is used for pattern matching, as explained in Chapter 2. So, when you use match (or fold), you are explicitly handling both the None case and the Some case. So, you could in theory emulate the behavior of alt by writing something like O.match(() => alternativeComputation(...args), O.some), however, not only that is more verbose, but it also doesn't tell your intention to the reader as clearly as O.alt does.
So you can pipe a series of alts together to perform coalescing, eg. you have multiple possibly None values, and you want the first one that isn't None
Yep, that's right! 👍 You can have multiple alts in sequence and you will keep executing them until one of them succeeds (i.e., returns a Some) or they all fail (i.e., all return None).
[Option] is not really an error. It's an optional value. [Either] is more suitable for error handling. Option just tells you if value exists or not. In real world it would be Either
That is not accurate. Option can be used to "represent the effect of a possibly failing computation" as stated in the fp-ts documentation. In fact, in the case in which you don't care about an error message or error type and you only want to know if the computation succeeded or not, you can totally use Option. Even in other languages, like Haskell, the Maybe monad (the equivalent of Option in fp-ts) can represent the result of a computation that can fail. Also in Rust, in the std::option module docs, it states that one of the uses of Option is as "Return value for otherwise reporting simple errors, where None is returned on error."
@@MrFunctor sure you can. But its confusing when there is no context of your "error". That's why I'm saying its not really an error. Computation can fail with many reasons. For example it's not ok to return Option when you parse uuid, or divide by zero but some people do it.
To summarize: technically it is "simple error" or fail. In real world you never use Option as an error
Yeah, I agree that when you have a function that may fail for different reasons, you should return an Either to be able to specify the kind of error that caused the function to fail. However, there are also cases in which you have simple functions that can fail for only one obvious reason and in those cases it makes sense to return an Option. In the video, we have getMovieAwardHighlight, which is a function that tries to get the movie.award and return an award highlight. However, if the movie has no award, this function "fails" and returns a None. So, in this case, it is clear that if you got a None, it must be because the movie has no award. The same applies to getMovieTop10Highlight: the only reason why that function may fail is because the movie is not in the top 10, so it cannot return a TOP 10 highlight, and that's why it's fine for it to return an Option.
@@MrFunctor again - no problem with using an option. My problem is i cant call it an "error"
Wonderful, thank you! Shed some light on two concepts I’ve been wanting to learn more about, namely .alt as well as W (Widen).
Is that how I should think when I encounter the W in the various methods? That the return type can be different than the original? Or was that only for this specific context?
Hello Dawid!
Yes, that's how you should think when you encounter methods that end in W: it just stands for Widen/Widening with the meaning that it is widening the return type. 👍
Most of the time, you don't want to unintentionally widen return types, so the default behavior tends to enforce that the return type remains the same. In a few cases, where you do need to widen the type, you have to explicitly call the W variant of a particular method.
@@MrFunctor Perfect, thank you!
Is this approach cleaner that using fold?
Remember that fold is just an alias for match, which is used for pattern matching, as explained in Chapter 2. So, when you use match (or fold), you are explicitly handling both the None case and the Some case. So, you could in theory emulate the behavior of alt by writing something like O.match(() => alternativeComputation(...args), O.some), however, not only that is more verbose, but it also doesn't tell your intention to the reader as clearly as O.alt does.