4 ms·

I’m confused by “listing 5” that states private methods and variables are accessible without reflection. The example it gives shows a static main within the sam

I’m confused by “listing 5” that states private methods and variables are accessible without reflection. The example it gives shows a static main within the same class that declared private. That’s the definition of private, that only the declaring class can access. I believe the main beef is that one object _can access_ another object, even though they are the same type. That makes perfect sense to me. How else would equals and hashcode work?

_pmf_ 9y ago
It's commonly called "inheritance anomaly".
- toolslive 9y ago
  "Inheritance anomaly" is something else. It refers to the combination of inheritance and concurrency not working out well together. https://dl.acm.org/citation.cfm?id=968159 https://dl.acm.org/citation.cfm?id=968159
mikejb 9y ago
> That makes perfect sense to me. How else would equals and hashcode work? It also makes perfect sense to me. Visibility is type-based, not instance-based. But to answer the hypothetical question: one would have to introduce class-private (package private?) getter methods for all relevant truly-private fields. I'm happy that's not the case.
kqr 9y ago
I can see both sides of the coin. It would make sense if the only way to depend on an instances hidden values was through its public interface. That way, each object is a truly independent actor, specified by and only by its public interface. You and me both belong to the general class of humans, but you still have to ask me if you want to borrow my money. I desperately need better nomenclature, but it is essentially what I think of as "implementation hiding for security and reliability reasons". You specify a small-ish set of methods that depend on the internal state of only this object, you verify their goodness, and then calmly implement all other operations in terms of those. Then Java is based on "implementation hiding for maintainability reasons" -- i.e. it's really important that if you refactor something private in a file, your commit should only have to mention that file, and no other file can depend on private members in other files. In this case, the "reliabiliy" perspective confers greater maintainability, at least in one dimension. On the other hand, much lower flexibility, as several people have mentioned already. In some loose sense, it's the distinction between a syntactic perspective (boundary crossing happens at the file level; the characters on screen determine what implementation hiding means) and a semantic perspective (the objects should occupy an utopia where they do not distinguish between each other based on class, if you excuse the pun. What matters is their allowed behaviour and that interaction.) I am afraid I have failed to express this in neutral terms because of my preexisting biases, but I hope the idea comes across anyway.
chopin 9y ago
I was surprised either. What I find odd: "protected" stuff can be accessed by classes in the same package, even if they not inherit the class with the "protected" member. I find this very annoying as I use protected and package-private for entirely different semantics. No scope qualifier means package-private for classes and public for interfaces. I never could wrap my head around this. That's bad user interface design. As well, I have package-private interfaces sometimes (which is perfectly possible), but their methods can only be public (which is unwanted if the interface is package-private).

_pmf_ 9y ago

It's commonly called "inheritance anomaly".

toolslive 9y ago
"Inheritance anomaly" is something else. It refers to the combination of inheritance and concurrency not working out well together. https://dl.acm.org/citation.cfm?id=968159 https://dl.acm.org/citation.cfm?id=968159

mikejb 9y ago

> That makes perfect sense to me. How else would equals and hashcode work? It also makes perfect sense to me. Visibility is type-based, not instance-based. But to answer the hypothetical question: one would have to introduce class-private (package private?) getter methods for all relevant truly-private fields. I'm happy that's not the case.

kqr 9y ago

I can see both sides of the coin. It would make sense if the only way to depend on an instances hidden values was through its public interface. That way, each object is a truly independent actor, specified by and only by its public interface. You and me both belong to the general class of humans, but you still have to ask me if you want to borrow my money. I desperately need better nomenclature, but it is essentially what I think of as "implementation hiding for security and reliability reasons". You specify a small-ish set of methods that depend on the internal state of only this object, you verify their goodness, and then calmly implement all other operations in terms of those. Then Java is based on "implementation hiding for maintainability reasons" -- i.e. it's really important that if you refactor something private in a file, your commit should only have to mention that file, and no other file can depend on private members in other files. In this case, the "reliabiliy" perspective confers greater maintainability, at least in one dimension. On the other hand, much lower flexibility, as several people have mentioned already. In some loose sense, it's the distinction between a syntactic perspective (boundary crossing happens at the file level; the characters on screen determine what implementation hiding means) and a semantic perspective (the objects should occupy an utopia where they do not distinguish between each other based on class, if you excuse the pun. What matters is their allowed behaviour and that interaction.) I am afraid I have failed to express this in neutral terms because of my preexisting biases, but I hope the idea comes across anyway.

chopin 9y ago

I was surprised either. What I find odd: "protected" stuff can be accessed by classes in the same package, even if they not inherit the class with the "protected" member. I find this very annoying as I use protected and package-private for entirely different semantics. No scope qualifier means package-private for classes and public for interfaces. I never could wrap my head around this. That's bad user interface design. As well, I have package-private interfaces sometimes (which is perfectly possible), but their methods can only be public (which is unwanted if the interface is package-private).