variable selection vs. method selection

[Ken Truitt]

The following program and output is supposed to help me figure out the interplay
between method selection and variable selection. I seem to recall somebody
saying something to the effect of 'overriding is for methods.' The idea was that
reference type chooses which instance variable is used. That's not what these
results indicate. Any clarification?

Note: I also did a version of this program in which I 'overloaded' the rocks variable
in class B by giving it a double type. The results were essentially the same. Is variable
overloading a valid concept?

   
public class InheritVar {

  public static void main(String[] args) {
    A a = new B(5);
    B b = new B(7);
    System.out.println("Given A a = new B(5) and ");
    System.out.println("      B b = new B(7)");
    System.out.println("call the following methods:");
    System.out.println("---------------------------");
    System.out.println("1)a.doRocks()  : " + a.doRocks());
    System.out.println("2)b.doRocks()  : " + b.doRocks());        //#1
    System.out.println("3)b.skipRocks(): " + b.skipRocks());
    System.out.println("4)b.getRocks() : " + b.getRocks());
  }

}

class A {
  
  A() {}

  A(int x) {
    this.rocks = x;
  }

  int rocks = 5;

  int doRocks() {
    return rocks;
  }

}

class B extends A {
  int rocks = 7;

  B(int y) {
    this.rocks = y;
  }

  int skipRocks() {
    return rocks;
  }

  int getRocks() {
    return super.rocks;
  }
}
 

-----------------------------------

output is:


Given A a = new B(5) and
B b = new B(7)
call the following methods:
---------------------------
1)a.doRocks() : 5
2)b.doRocks() : 5 //expecting 7 here
3)b.skipRocks(): 7
4)b.getRocks() : 5

[Wirianto Djunaidi]

Ken,

You can't override variable. When you declare same variable name like that, then there are 2 rock variables in different scope. 1 in A's scope, and 1 in B's scope. So when you access from within B, by default you get the variable declared in B. You can access the one in A scope from within B explicitly by using super.

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.

[Ken Truitt]

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. Inheritance
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.

[Henry Wong]

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.

No. It's right. The variable that is accessed is based on the reference type used to access the variable. The problem is that you are mistaken on the reference being used.

You are assuming that the reference is a B reference, since the b variable is used to call the method. However, the doRocks() method doesn't know about the b reference. It is using the "this" reference to get to the instance variable. And since the doRocks() method is a method of the A class. The "this" reference is a A reference.

Henry

[Ken Truitt]

OK so it's as if 'this.' prepends every variable reference in the "inherited" method?

I have that in quotes because that word has caused my confusion. The only thing a subclass appears
to "inherit" from a superclass method is access to the superclass scope. That is, it is not as if
an inherited method really becomes part of the subclass at all.

Now...what if a superclass variable is initialized by a superclass method which is overriden in the subclass,
and that variable is referenced by 1)a superclass reference containing a subclass object and 2)a subclass reference
containing a subclass object? I guess I'll go find out...

[Henry Wong]

I have that in quotes because that word has caused my confusion. The only thing a subclass appears
to "inherit" from a superclass method is access to the superclass scope. That is, it is not as if
an inherited method really becomes part of the subclass at all.

Implementation-wise, it obviously doesn't, if you call a method that is not part of the subclass, it will route it to the super class.

Think about it this way. If a class truely got copies of the methods, then wouldn't each class be huge?!? If you subclass another class just to override one method, your new class file would be huge, as you would still need copies of every method up the inheritence true.

Furthermore, references (like "this") from the superclass methods are based on the superclass. If the subclass, needs to have a copy of the method, it will need to recompile, in order to fix this. This means that you need the source code of the class that you want to inherit from.

Henry

[Ken Truitt]

I found out...

The inherited variable gets the value assigned by the subclass method in each case.
I wondered whether the initialization statement would take place in the A scope and
it wouldn't "know about" the B override. Very interesting...

(this code is for an applet that i use which immitates the command line cmd.exe app)

/* OUTPUT

 a.x is 4. b.x is 4

*/


import nocmd.Template;

class A {

  int x = getX();

  int getX() {
    return 3;
  }

}

class B extends A {

  int getX() {
    return 4;
  }

}

public class Test extends Template {

  public void main(String[] args) {
    A a = new B();

    B b = new B();

    println("a.x is " + a.x + ".  b.x is " + b.x);
  }

}