• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

variable selection vs. method selection

 
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?




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

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



 
Ranch Hand
Posts: 218
VI Editor Ruby Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.
 
author
Posts: 23919
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
author
Posts: 23919
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)



 
look! it's a bird! it's a plane! It's .... a teeny tiny ad
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic