Now imagine that your

getPort()

function calls a function that also needs something from that config, but a different parameter

Welcome to monad transformer hell

which are a requirement because monads do not compose

yeah, I see how that can be a pain.

So 1) destroys encapsulation, 2) modifies the whole stack call of signatures 3) requires monad transformers to be effective and 4) requires for callers to figure out how to materialize the thing being passed

yep

Me, I prefer to call

getPort()

and say “Guice, give that function a

Config

somehow, I don’t care"

This is why these

Reader

blog posts irk me: because their authors are either unaware of these deficiencies or they are intentionally not disclosing them in an attempt to make

Reader

appear as a silver bullet with no downsides. Either way, bad literature.

So, the way I normally get around this, is to split the application into small libraries (or think of them as small libraries that are separate from the app). And refrain from adding

@Inject

or

@Autowire

all across the code base. That forces me to think explicitly about all these dependencies. With Spring, I normally wire them together using

@Configuration

instead of polluting everything with spring annotations.

One of my pet peeves is seeing Spring Apps with huge classes annoated as

@Services

and things auto-wired all over the place.

That also makes it hard to change.

I think you can arrive at a good middle ground (despite what method you use), if you force yourself to have a thin layer that does all the wiring. I’ve been bitten too many times with code bases that have no restriction on how they scatter spring annotations

The interdependencies exist regardless of how you resolve them, @Inject or Reader.

Whether you want it or not, your class that contains

getPort()

depend on the

Config

class.

So, if you are using an external library, that has a

getPort()

, you don’t go in and modify that , right?

The way you architect your application cannot change that.

that is only an issue with our own code

I don’t understand your point

if you need to use an external library, you don’t open it and annotate it, right?

I see your point, and it does happen, but I think it can be contained to the edges of an application with some discipline.

oh, btw, another question I had, what is the difference b/w dependency passing vs dependency injection? I hadn’t heard the term

dependency passing

before, and googled it and it was just resolved to

dependency injection

.

I made it up

to accurately describe what

Reader

does and contrast it with dependency injection

It’s dependency passing because you have to pass that config object to

getPort()

, that’s part of being referentially transparent: all the parameters must be passed to the function

getPort()

needs a

Config

object. DI will inject that object directly in a field of the class, Reader forces you to pass it as a parameter (another downside by the way, now

getPort()

is

getPort(config: C) : Reader[C, Int]

)

Scala will give you the illusion that it doesn’t because it will pass that parameter implicitly

but don’t be fooled 🙂

hmm, for something similar in a Kotlin project, we had a

PersistenceContext

and I just added an extension function to it (getProperty), that way we just passed that down, and called

context.getProperty

. What I didn’t like was that … well, I had to pass in a

PersistenceContext

instead of just the explicit property I wanted.

these were libraries for contacting external APIs, so for example a function in one of these classes looked like

getSomethingFromX(persistenceContext, request)

the last thing they did before I left the team was to add spring to the libraries to auto wire them, which I disagreed with, I would have preferred to change the signature of the functions to

getSomethingFromX(host, request)