Commenters propose alternative framings of the rule
2 Oct 31 2:25 PM · 11d ago · 1 post · 8 comments · 2 sources · development 2 of 4
Lobsters commenters offer concrete experiences and reframings: andrewrk describes a stack-trace use case that depends on the pattern, azimux argues the deeper issue is damaging a function's public interface rather than the call itself, and telemachus questions whether the example should use two distinct private helpers instead of one.
“I feel like the better more general rule would be something like "do not damage the public interface unless absolutely necessary."”
azimuxmatklad Blog post authorandrewrk Lobsters commenterazimux Lobsters commenterdavid_chisnall Lobsters commenter
The whole story postscomments the bright band is this development · numbered dots are the others · click one to jump
What people said 8 voices · verbatim
-
The problem I see there is not that foo calls bar specifically, but rather that bar's public interface has been damaged as an implementation detail of foo as opposed to a tiny refactor. So I feel like the better more general rule would be something like "do not damage the public interface unless absolutely necessary." Though, if using the avoid…
-
A concrete thing related to this I just ran into yesterday, is that when reporting certain kinds of errors, I collect a stack trace for later rendering to indicate which public function call was responsible for the creation of a particular artifact. You can make the first stack frame be the callsite of the public function by capturing the return…
-
I've been in the shoes of a developer adding optional function after optional function to make things "easier" for users. Some of the worst APIs grow this way. "Everything is in one function call" except that you've effectively reinvented having multiple functions by way of parameters. Also, "sanctified ink" is definitely a phrase I will be using…
-
I see how having both `foo` and `bar` call a private helper improves the public API. But I immediately wondered why not have *different* private helpers, `frobnicate` and `transmogrify`. (To put this another way: `helper(.frobnicate)` and `helper(.transmogrify)` struck me as swapping the original flag boolean for a flag enum.) I guess it all…
-
> Which is, imo, a natural, but horrible consequence of misguided approach to testing. You shouldn’t be mocking your methods, you should mock your IO Is mocking a `MyCustomResourceStore` “mocking your IO”, or does “mock your IO” refer to some lower layer of the I/O stack? Where does I/O begin?
-
Data that comes from or goes outside the program itself. This can be a file, a socket, a TTY, environment variables, command line parameters, that type of stuff. When I made my [DNS library](https://github.com/spc476/SPCDNS) I explicitly separated packet receiving/sending from parsing/generating (you get a DNS packet, *then* send it to be decoded…
-
That was my thought too, but I assumed that it was just an example and that it shouldn’t be looked into too deeply.
-
Re: the private methods, I suppose I feel like either could be refactored into the other without much issue. I'm viewing it more as that one problem with extra stuff exposed through bar is that somebody outside could couple to that and now removing it breaks stuff. That is, we could improve the internal code-quality of the implementation as…
All 4 developments of matklad's 'don't let public functions call public… →
Hacker NewsLobsters