Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad
1–10 of 20 posts
Re: Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad
#2Great 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!
Re: Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad
#3Great 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 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.
Re: Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad
#4Great 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…
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.
Re: Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad
#5Great 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…
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.
Yeah, I agree the injected functions being "marked" by their types is nice.
Re: Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad
#6Great 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 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.)
Re: Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad
#7Clearest blog post I've read on the Reader monad in Scala. This is something I can see coming to our code base very soon.
The next step for us is monad transformers in Scalaz. We are going to end up with something like Future[Reader[Writer[Problem \/ Result]]] (a few type parameters are missing there; hopefully you get the idea). Monad transformers give a way to flatten this stack of monads into a single monad, which saves a lot of unnecessary wrapping and unwrapping in code. I haven't yet worked out the all the details of using them, though. Should probably do a blog post when I do :-)
Re: Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad
#8Earlier quoted context omitted.
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.
Re: Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad
#9Clearest blog post I've read on the Reader monad in Scala. This is something I can see coming to our code base very soon. The next step for us is monad transformers in Scalaz. We are going to end up with something like Future[Reader[Writer[Problem \/ Result]]] (a few type parameters are missing there; hopefully you get the idea). Monad transformers give a way to flatten this stack of monads into a single monad, which…
I've been thinking about using scalaz for a while now. My main concern about the above pattern is the type complexity that will arise. I would love to learn more about monad transformers and how they help out with that issue.
Re: Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad
#10Earlier quoted context omitted.
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.
Cool thanks, didn't realize it was due to implicits.
Here are my tests, for the record.
Works in Scala:
for {a do a