Hacker News Reader

Comment by default-kramer | Hacker News Reader

> What would it even look like for the top-most function to have to know “everything” that all the child functions end up ever needing? For every function parameter change in the entire program to somehow force a change all the way up the entire call stack? Clearly this does not happen. It so thoroughly does not happen that you may be having difficulty even imagining what it is I am talking about.

Really? In my experience, it certainly does happen and I'm generally happy (but not thrilled) when it does. It means the type system is doing its job, forcing me to provide all the dependencies that a function needs. If 38 layers deep something now needs a connection string that it didn't have before, that had better bubble up to the top-most function. Unless of course the top-most function has already provided it to an intermediate layer which can break the chain, but that is very different than the context.Background() example.

View on HN

Yeah, in my experience it absolutely can happen, and the way it generally looks is that the dependencies get roughly grouped into larger structs which are then being passed down the call stack mostly as-is, until they hit a certain abstraction level/barrier where the parts of those structs start being passed down.

It's somewhat tedious, that's why modularity becomes even more important: with correctly chosen borders, the grouping of dependencies becomes very clean and self-evident, the whole data flow just flows. Chose them wrong, and you spend most of your time adding and removing those pesky extra arguments.

Yes, when considering software design it's great when you can "smuggle in" a new dependency by adding a new property or method on some already-established payload. I would describe this as "The change requires someone way up the stack to change, but all the intermediate layers require no source changes" which is notably absent from the author's list of "three basic cases that can emerge." I assume the author is well-aware of this technique but considers it equivalent (for the purpose of function coloring) to "The change may require a change to all functions in the stack" since technically the signature of all those intermediate layers did change.

Your configuration structs are not "everything". You probably have dozens of things in them. You have hundreds to thousands of different parameters to different functions. By the time your configuration structs have hundreds of things in them you have thousands to tens of thousands of parameters to functions. Only a fairly small fraction of things make it all the way up to main.

This is exactly what I was talking about with this being a "cognitively available" operation. You notice when you have to propagate something all the way up to the top precisely because it is not something you do very often and it stands out as an exception when you do. If you are literally propagating everything up to main, all the time, every time you change any function anywhere in your program, you are doing something very, very wrong.

I'm not talking about configuration structs, I'm talking about actual, constructed dependencies being passed around in large sacks, sorry, structs.

And you don't have to propagate every parameter up to main because a) not all things are made in it, b) things that are being made in it are already being made in it and so, are already being passed down. This passing down stops down somewhere, which is where you reinstate it, not all the way up in main.

You should be passing a connection or a connection pool, not a connection string.

I chose a connection string as an example of something that obviously cannot be originated in the middle of the call stack. The difference between passing a raw connection string or passing a connection factory is important for good software design, but I considered them equivalent in the context of this discussion of coloring.

Reply on news.ycombinator.com