• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

runtime method call, as opposed to compile time method call

 
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am still having issues with this...perhaps I can explain my thinking and somebody can once again tell me how I'm wrong.
Ok so lets say I have a superClass and a subClass. and lets say I do something like this: superClass a = new subClass(), where subClass extends superClass. Now lets say both classes declare a method called public void getSize(), and also has a member variable called protected int size.
Is it true, that for methods which are overridden(as opposed to overloaded), the compiler will see what type of reference the object is...in this case superClass and then see if there is another overriden version of that in the subClass, if there is then it'll take the one that is closest to whatever Object type the variable is (instead of reference type).
However if the methods are overriden but static, then the compiler will go to the objects reference type - in this case superClass - and stop there if it sees the appropriate method, meaning it won't even try to look at the subclasses to see if there is a more "object-type-appropriate" method.
However for member variables. The compiler will treat a call to the member variable in the same way it treats static overriden methods - it stops at the superClass, and doesn't look down the hierarchy.
Now finally for overloaded methods, the compiler will go to the top of the hierarchy - in this case superClass - and work it's way down to the lowest applicable method. So does this all sound right, or is my logic still totally off?
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're close...
1) The overriding method is the one that will be selected at runtime. In other words, the lowest one in the class hierarchy, as you described.
2) Your understanding of how it works with static methods is correct, but not your terminology. We do not say that they are actually *overridden*. You *can* redefine a static method in a subclass, when that method also exists in the superclass, but polymorphism does not apply, so the method is selected based on the reference type.
3) Same with instance variables, as you pointed out. If you redefine (shadow) a variable in a subclass, when that variable also exists in the superclass, both values are present as part of the subclass object, but which value is used depends on the reference type, not the actual object type.
4) With overloaded methods, there's no real issue, you can call a method based only on whether that method exists in the class of the *reference* type, so if a subclass overloads a method from the superclass, you can't get to that new overloaded method using a reference to the superclass.
hope that helps,
Kathy
 
Wilson Mui
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes kathy you are right, I have started to more appropriately use the term hidden for static methods which are declared both in the super class as well as the sub class...and like you said, in that case the method that is defined by the reference type will be executed...
But a step further, what if the reference type class doesn't define the static method that is being called. For instance
SuperClass A = new SubClass();
A.getSize()
but lets say getSize() isn't defined in SuperClass but only in SubClass, does it throw a compile-time error, run-time error, or default to a "lower hierarchy" method?
I am going to try it out as well, but I would still appreciate a response, because that bolsters my assurance that I did not screw the code up and make it work some how another way.
 
Kathy Sierra
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I almost forgot about another really FUN one... what happens with overloaded arguments?
Here's where it gets a little weird -- polymorphism does not apply when selecting between two overloaded methods. Which of two overloaded methods will be chosen depends on the REFERENCE type, not the actual runtime object type:

Can you guess what the output is? Don't scroll any further unless you want the answer
kathy% java Tester
in the one that takes a parent
parent
in the one that takes a child
child
in the one that takes a parent
child
==================
explanation:
Parent p = new Parent();
Child c = new Child();
Parent pc = new Child();
Tester t = new Tester();
t.doStuff(p); // selects the one that takes a Parent
t.doStuff(c); // selects the one that takes a Child
t.doStuff(pc); // selects the one that takes a Parent
// even though it is really a Child!
cheers,
Kathy
 
Wilson Mui
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
woohoo I guessed right...emphasis on guess...but actually I think I've come across something like that. And I think the explanation said something of the sort that overloaded methods (like the case you just presented) must be resolved at compile-time. And I've rationalized it to myself that, compile-time resolution means, the compiler has to make a choice right now, during compilation which method to choose. And since I think to myself the compiler can't be that smart, and actually look to see what the real object type is, it can only look at the reference type, because that information is glaring in its face. in which case it will choose the method that matches it's reference type. Do you think that is a good way of thinking about it.
And I've broken down my idea into a few easy, verbal rules (along with my whole compile-time vs. run-time rationalization described above). For overridden methods it is determined at run-time, so it has the time to actually see what the object is, so it goes "down" the hierarchy tree, and gets the object specified method. For static methods, and member variables, first off they aren't really overriden-they are hidden, and also overloaded methods (like the one you just described), they are resolved at compile-time, since the compiler isn't very smart, or doesn't have time. The method that they will call will be the reference type method.
and if that method or member variable is not defined in the superClass, it will throw a compile-time error (well since all this stuff was determined at compile-time).
Ok, does that sound right?
 
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
and also remember that overloaded methods can be inherited by the sub classes down the hierarchy... dan's exams on overloading was a eye opener... thanks dan
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic