|
|
|
|
|
|
by 11Di
2260 days ago
|
|
|
For comprehensions should alleviate the examples you have given with regards to readability. Although yes there are other more complex instances in which nested matches might come up. Generally I would think to handle them by creating a function that contains the next layer of matching instead of trying to come up with an uber function. Adds a bit more verbosity perhaps but I find it is fairly easy to follow and show intent. |
|
|
What I should have asked was: if you're using monads such as Option, then how do you use them effectively without using integral tools such as flatMap?
And you've answered: you can use for comprehensions. I primarily have used Haskell and OCaml, so I sometimes forget about Scala's very nice for comprehensions, which I agree is a great solution. But note that for comprehensions are just syntactic sugar for `flatMap`.
I agree that if you do use Option types in Scala, for comprehensions are a very elegant way to interact with them.
But I'll end with a question. If you're already using option types with for comprehensions, why not also throw in other useful monads like bifunctor IO, which is a great way to deal with async code? I understand the dislike for the tendency in the FP Scala community to use custom sigils, but I do think most people who are using options and for comprehensions would also be comfortable and happy using other useful monads with for comprehensions.