On Sunday, July 13, 2025 8:38:08 AM Mountain Daylight Time H. S. Teoh via Digitalmars-d-learn wrote: > 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.
Yeah, there are a bunch of different ways to go about designing APIs, and if they're sufficiently component-based, that can definitely help with composability and reusibility. However, my point is that the public API needs to be designed with the purpose that it's public and that it will be used that way. Anything that isn't designed to be used by other developers should be private - both because it causes maintenance problems if it's not, and because it will probably have the wrong design if it wasn't specifically designed and tested as part of the public API. Nothing should be public by accident or just because it exists. It should be a purposeful design decision. And if someone wants to design an API where private is barely used at all, that can be perfectly fine - or even desirable, depending on the situation - but it should be purposeful, and any public symbols should be properly designed for public use, because by making them public, they're part of the API. And at the end of the day, when it makes sense to make something private and when it makes sense to expose is in large part up to the developer writing the code, with both approaches making sense depending on the circumstances. As it is, Phobos in general doesn't hide a lot of stuff behind private precisely because its range-based approach to most things tends to make it so that a lot of the code is very component-based, but there are still cases where private makes sense, and to an extent, that's a judgement call, but whatever is made public instead of private needs to be designed with that in mind, because making a symbol part of the API is a contract with the user and creates a maintenance burden, whereas private symbols are an implementation detail. - Jonathan M Davis
