4 ms·

> OOP-world analogy was always shallow to begin with I would also add that the purpose of visibility is to encapsulate and not some sort of access control. All

• throwup238 3y ago
  What do you mean by access control? I don't know if this falls under the umbrella of encapsulation as well, but often in Rust I'll mark members of a data structure private so that it can't be constructed except by approved functions exported by the same module that contains the data structures. As long as team boundaries are enforced at the repo level, this becomes great access control.
  • dwaite 3y ago
    I think the parent was saying that private/protected aren't used to protect secrets, they are there to make code more maintainable when you have a split between implementation details and stable/revisioned public api "contract". You want to understand exactly what code may be depending upon implementation details and limit it (encapsulation) for reasoning and maintainability. I'll give a counterexample of this being done wrongly - Java has a pretty common development pattern where up-front you make a member private, and then write pass-through getter and setter methods. This doesn't really provide much for maintainability, because you have started out needing to support arbitrary retrieval and modification from anywhere, and have likely externalized interpretation of the data the member represents.
  • carstimon 3y ago
    I think this is in response to > Why should my Dog be able to check out the internal StomachContents of another Dog This seems to be interpreting the purpose of visibility as controlling the access that actual things represented by objects have. (There could be a non oop-as-real-world-things example here; `UserProfile.equals(UserProfile other)` might access secrets of `UserProfile` that the different actual users are not supposed to see between each other.) The reason Dog can check the internal details of another Dog is, there's a single file that controls the usage of the fields. If you decide you want to change the semantics of the stomachContents field, you can check all the usages in that file. That's the simple practical reason. The StomachContents thing seems like a confusing analogy, like most that compare OOP to Real World Categorization.
  • 3np 3y ago
    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).