The point is not about if schnauzerA instance can access stomach contents of dachshundB instance but about the classes Schnauzer and Dachshund. Any dog instanc

The point is not about if schnauzerA instance can access stomach contents of dachshundB instance but about the classes Schnauzer and Dachshund. Any dog instance would be inheriting and refering to the same implementation and the class has an inherent link to it. Contrast this to other classes, which may or may not ultimately be interfacing towards the exact implementation available at the time. One practical aspect: If some private function is changed or removed in a patch release and not mentioned in release notes and your code using it breaks, that's entirely on you. It's not that you aren't allowed to futz around with it, it's that it's not part of the contract. If you hook into class internals and stuff break in an unexpected way when you upgraded and didn't manually go over the code diff, that's entirely on you. This is different from, say, guaranteeing that data never crosses boundaries or otherwise as a security measure. It's about separation of concerns, not security. > As long as team boundaries are enforced at the repo level, this becomes great access control. If you're talking about an an internal codebase where this is strictly enforced, I'd argue that those measures are what would constitute access control. Fundamentally it's not much different from a library author proclaiming "users may only be calling functions starting with letters A-H". Does putting linting rules in place for that turn it into access control? What you're actually talking about is sounding more like object capabilities (ocaps).