On Sat, Jul 12, 2025 at 06:35:42PM -0600, Jonathan M Davis via Digitalmars-d-learn wrote: > On Saturday, July 12, 2025 5:55:39 PM Mountain Daylight Time Ali Çehreli via > Digitalmars-d-learn wrote: [...] > > Meanwhile, engineers like you suffer because of 'private'. I pick > > engineering over 'private' any day. > > Whereas I think that using private makes perfect sense when you want > something to be an implementation detail. Exposing it means that you > have to deal with someone using it, you have to design its API for > public use, and you can't change it without breaking code. If > anything, making something public when it doesn't need to be makes it > harder to maintain and refactor that code. As far as public libraries > go, any time that any symbol is public, someone is going to use it, > and you're stuck with its design. > > And when the code is open source, if someone wants to use it, they can > always just copy it into their own code and do whatever they want with > it without creating any additional burden for the maintainers of the > library that the code was taken from.
My own take on this is that public APIs should be designed from the POV of empowering the user. I.e., provide them with composable primitives that they may use to construct their own solutions, instead of forcing them to use your chosen way of solution. Your chosen solution could be the default, for those users who just want to solve the problem without investing more time/effort into researching their own solution, but the components from which your solution is constructed should be made available to the user so that they could use it to build their own if they wish. I view this as empowering the user, rather than spoon-feeding them. >From the POV of this approach, most things would be public, and only a few things would be private. Private stuff would be those things that you don't want user code to touch because it would break guarantees and/or cause other problems. This pertains to implementation details on the level of member variables and the like. But if your implementation has an entire class hierarchy inside, say, or some container, I'd argue that those are "external" or externally-reusable components that should be separately accessible rather than artificially locked under the hood. I.e. they may be part of the reusable components users could use to construct their own solutions. I find that often, implementing my solution in terms of components potentially open for user reuse often causes me to come up with better designed code than a solution-specific implementation that tends to become overly complex, because it's a monolithic solution that tries to do everything, and I didn't discover a good decomposition of it into reusable components because I didn't have to. --T
