3 ms·
This is very clever, and I wish I had figured this out when I ran into the same problem last summer. A little "smelly" but better than being forced to publicall
by kough 10y ago
This is very clever, and I wish I had figured this out when I ran into the same problem last summer. A little "smelly" but better than being forced to publically export implementation details.
That said, to play devil's argument, why not just make all implementation details public? I will say I remember being pissed off by Go packages that don't publicize all of their types and interfaces, which made writing tests against their behavior (usually requiring mocking, hence the need for the publicized types/interfaces) to be painful/impossible.
- gohrt 10y agoWhy are you testing the behavior of types not visible to your code?
- radub 10y agoThank you! Making everything public runs the risk of other modules using internal implementation details, and that entanglement makes changing things a lot harder. For a small project where you can easily control this, it's likely not an issue. But we are big enough that no one person knows all the code changes that are going on in all modules. Exported vs non exported also serves as implicit documentation, it makes understanding things easier when you can tell right away what is internal and what is not.