Also when working with Reader, it was a bit hassle when 3-4 function that have Reader as return type...

# arrow

[Satyam Agarwal]

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 😞

[raulraja]

Reader is not a good pattern in Kotlin because kotlin already has receiver functions

[raulraja]

so ReaderT<Deps, IO, A> is the same as

suspend Deps.whatever(): A

[raulraja]

or

[raulraja]

Deps.whatever(): IO<A>

[Satyam Agarwal]

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

[raulraja]

here is two different patterns for DI in case it helps https://gist.github.com/raulraja/97e2d5bf60e9d96680cf1fddcc90ee67

[raulraja]

Using receiver and arguments bounds you can eliminate calls to prefixes like `service.function`for just function

[Satyam Agarwal]

Ah. This is so much better. Thanks a lot. I’ll try to implement this.