Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Doubt in K&B SCJP 5: protected access

 
Peter Schubert
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On page 36, the book says:

The bottom line: when a subclass-outside-the-package inherits a protected member, the member is essentially private inside the subclass, such that only the subclass and its subclasses can access it.


However, a neighbor of the base class can still access the protected member in the subclass.

Instead, it should probably say:
...the member retains the protected access, as if in the original package of the base class.
 
Surendra Kumar
Ranch Hand
Posts: 236
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what do you mean by neighbor of base class?

However, a neighbor of the base class can still access the protected member in the subclass.
 
Keith Lynn
Ranch Hand
Posts: 2409
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think in that particular statement they were talking about classes and packages outside of the package containing the superclass.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There was similar (long) discussion a little way back.
 
Peter Schubert
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Surendra Nichenametla:
what do you mean by neighbor of base class?



I was refering to a class in the same package as the base class.
 
Peter Schubert
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Keith Lynn:
I think in that particular statement they were talking about classes and packages outside of the package containing the superclass.


The previous paragraph on the same page starts with
But there's still one more issue we haven't looked at...what does a protected
member look like to other classes trying to use the subclass-outside-the-package to
get to the subclass' inherited protected superclass member?

which does not limit the discussion to classes outside the package of the base class. Even if the example uses a "Neighbor" of the subclass-outside-the-package, the statement I was referring to in my original post is a "bottom line", which tries to generalize the conclusion.
 
Peter Schubert
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Barry Gaunt:
There was similar (long) discussion a little way back.


Thank you for pointing that out! I tried to find a similar thread before posting this, but I seem to have missed this one.

However, the discussion there focuses on the private-like access for classes in the same package as the subclass, and the distinction between "almost the same effect as private" and "private per se".

My point is that a better analogy could be made with the protected access instead of private. I think it's easier to remember that an inherited protected member still acts as protected, but it also "remembers" the package that "protects" it.

Here's also an example of what I'm trying to say:
 
Bert Bates
author
Sheriff
Posts: 8900
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all, this is actually Kathy answering the question under Bert's account.

While we're talking about my "bottom line" statement, I think the REAL "bottom line" is that Peter is absolutely right:

"My point is that a better analogy could be made with the protected access instead of private. I think it's easier to remember that an inherited protected member still acts as protected, but it also "remembers" the package that "protects" it."

I oversimplified with a way of thinking about it that supports anything that would ever be asked on the exam, but breaks down where Peter demonstrated. We always struggle with this... we DO sometimes oversimplify and leave off edge cases, following kind of a 95/5 rule... where the [simpler] thing we discuss covers 95% of the topic, and 100% of what you'd get on the exam, where the extra 5% would add way too much cognitive overhead for virtually little or no gain.

Peter's argument, however, is an example of where we didn't get it right...because his way of explaining it is just as simple, but more correct!

Thanks Peter. We'll flag this for our next revision.

Cheers,
Kathy
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic