Also when working with Reader, it was a bit hassle...
# arrow
s
Also when working with Reader, it was a bit hassle when 3-4 function that have Reader as return type. I was `ask`ing and `extract`ing many times. Ofcourse that because of my limited fp exp. Perhaps ReaderT could’ve simplified it, but I never got it working 😞
r
Reader is not a good pattern in Kotlin because kotlin already has receiver functions
so ReaderT<Deps, IO, A> is the same as
Copy code
suspend Deps.whatever(): A
or
Copy code
Deps.whatever(): IO<A>
s
Yes. I actually looked at that pattern as well from the article. Tried to implement it and then it quickly became large and was not nice to see so many extension functions on single dependency, further in part 2 type classes clears this makes it much nicer but I haven’t came that far long to use it fully unfortunately
r
here is two different patterns for DI in case it helps https://gist.github.com/raulraja/97e2d5bf60e9d96680cf1fddcc90ee67
Using receiver and arguments bounds you can eliminate calls to prefixes like `service.function`for just
function
s
Ah. This is so much better. Thanks a lot. I’ll try to implement this.
👍 3