On Tue, May 25, 2021 at 04:24:39PM +0900, Stephen J. Turnbull wrote:
In Support For Private, however, we're talking about a positive-sum game. Code writers need to communicate with code readers, both human and machine, while avoiding mistakes. In fact, this is almost a purely cooperative game.
It's not really purely cooperative. API consumers always want more than the API designers are willing or able to give. Developers of the API want to hide as much of the system as possible, so they can change it without breaking consumers' code. But consumers want access to as much of the system as possible, so they can do things the developers never thought of when they designed the API, or for performance, or just so they can write one line instead of two. This leads to the well-known conflict between spending resources keeping backwards compatibility, or breaking people's code when you change features. E.g. Microsoft is well-known for the first strategy, up to and including detecting when a specific application is running and emulating the bugs that it relies on. Yes, Microsoft has been known to port bugs from one version of Windows to the next, and I'm not being snarky. Apple, on the other hand, is much more strict and willing to ban or break code that uses features they don't want you to use. "We told you not to do that." In languages that have access controls such as private, protected, final etc, there is a strong tendency for those controls to be over-used by API designers, which then leads consumers of the API to make huge efforts to bypass the controls or work around them. https://stackoverflow.com/questions/27859296/how-to-access-private-class-met... https://www.websparrow.org/java/how-to-access-private-fields-methods-and-con... That's clear evidence of conflict, not cooperation. Now obviously those bypass mechanisms had to be added to the language by the API designers. So even the Java designers recognise that other people over-use private, and so built an entire mechanism (reflection) to allow consumers to bypass it when needed. -- Steve