Great use of the same example under three different dependency injection mechanisms.
One issue I see with the Reader pattern, however, is that anyone using one of these injected methods has to deal with the monad stuff of using for comprehensions to extract the values, et cetera, whereas with the other two patterns they get to use normal functions.
Put another way: having to distinguish between the "normal" functions in a class versus the injected Reader functions, and not be able to use them in the same way, feels like it would get old fast. I wonder if the author has found this annoying or not.
I do really like how purely functional the Reader approach is though, no state!
I actually like using comprehensions in Scala so I don't find it annoying at all. Also I think having a clear distinction between the "normal" and "injected" functions is a good thing.
I do find having to add implicit parameters to every function slightly annoying, especially because when I forget, it's not always clear from the compiler error what I did wrong.
in general your repository functions will be wrapped in some monad, whether it's Reader/Maybe/List doesn't really matter as far as the for comprehension is concerned.
Yeah, I guess that helps a little since Scala's for comprehensions let you mix monads. (Which, for the record, Haskell's otherwise similar do notation doesn't seem to allow.)
Technically, Scala's for comprehensions don't let you mix monads either, but implicit conversions make it work in some cases. For example, there's an implicit conversion from Option to Iterable so the Option (Maybe) and List monads can be mixed. It's really more a matter of Scala's type system allowing it. The Scala compiler just re-writes comprehensions into equivalent higher-order function application.
One issue I see with the Reader pattern, however, is that anyone using one of these injected methods has to deal with the monad stuff of using for comprehensions to extract the values, et cetera, whereas with the other two patterns they get to use normal functions.
Put another way: having to distinguish between the "normal" functions in a class versus the injected Reader functions, and not be able to use them in the same way, feels like it would get old fast. I wonder if the author has found this annoying or not.
I do really like how purely functional the Reader approach is though, no state!