Since doRocks() belong to A class, it can only access A's rocks. B inherits doRocks() only imply that B can call doRocks(), but doRocks() can not access any variables that belong to B because it does not have awareness of them.
You make it sound as though when b.doRocks() runs, it's not so much that b inherits doRocks() as that it
accesses the doRocks() in A. I'm not so comfortable with the concept of the superclass's scope
is inheritance. If B extends A and they both are in the same package, then B GETS any members that are not
private from A.
I got the idea somewhere that variable choice, as opposed to method choice, follows essentially the same rules
as overloading--it's based on reference type. Unfortunately, that appears to be entirely wrong.
This is an interesting case because B doesn't override
doRocks(), it simply inherits it. If B did override doRocks()
then b.doRocks() would have returned b's version of rocks, 7. So it seems that there's a rule 'a variable referenced in
a method corresponds to the the declaration of that variable in the same class as the method version that is running.'
Except that that wouldn't be the case if doRocks() was called from b and B did not declare a version of rocks, but DID
override doRocks(). In that case B's doRocks() would run, but it would return the value inherited from A.
Anyhow, thanks for the heads-up.