dynamic method lookup

[Nasir Khan]

Hi Friends,
Consider the code
_____________________________
class guitar{
private String play(){return "rock";}
public String go() { return play(); }
}
class ibanez extends guitar{
String play(){return "metal";}
}
class music {
public static void main(String s[]){
guitar g=new ibanez();
System.out.println(g.go());
}
}
__________________________________
Could anyone explain the outcome....
I know it got to do somthing with dynamic method lookup but
still the concept is not that clear to me.
please help!

[Roopa Bagur]

I think the final outcome will be "metal" because in the main method though g is of type superclass it is pointing to the subclass object therefore the play() method of the subclass will be called.

Originally posted by Nasir Khan:
Hi Friends,
Consider the code
_____________________________
class guitar{
private String play(){return "rock";}
public String go() { return play(); }
}
class ibanez extends guitar{
String play(){return "metal";}
}
class music {
public static void main(String s[]){
guitar g=new ibanez();
System.out.println(g.go());
}
}
__________________________________
Could anyone explain the outcome....
I know it got to do somthing with dynamic method lookup but
still the concept is not that clear to me.
please help!

[Rashmirekha Sahoo]

Hi Roopa,
No the outcome will be 'Rock' as the subclass 'iBanez' doesn't have 'go' method. Hence the 'go' method of base class is being called. If the subclass had a 'go' method, then it would have called play method of subclass.
Waiting for new responses.
Rashmi.

[shree vijay]

<code>
class guitar{
private String play(){return "rock";}
public String go() { return play(); }
}
class ibanez extends guitar{
String play(){return "metal";}
}
class music {
public static void main(String s[]){
guitar g=new ibanez();
System.out.println(g.go());
}
}
</code>

Hi, i think i can get a bit.
When the compiler compiles a program, it checks whether the method you call is accessible.
Consider the assignment
guitar g = new ibanez();
and then,
g.go()
when the compiler sees g.go() it checks the type of the variable g. The type of the variable g is guitar. And the go() method is of course available in the class guitar. So, it compiles fine.
But when the program is run, then what really matters is the type of the object you have assigned to the reference, not the type of the reference. Here the type of the object in memory for the reference g is ibanez. Now the question, is does ibanez class have the go method? Yes, it does, because it inherits it from the base guitar. So, the method call to the base class method is issued. Now, the go() method calls the play() method of guitar. (This is the case of the private play() called by the other member method go() which is perfectly legal)
Therefore, the output is 'Rock'

------------------
Regards,
Shree

[Ashish Agnihotri]

Hi Sree !!
Are you a tutor !!
Excellent explanation.
tks,
Ashish

[Jayii Young]

The outcome is "rock";
In class guitar, the method play() is private. In this case, guitar.play() cannot be overridden by any subclass of guitar.

[shree vijay]

Hi Ashish,
I got clear due to a reply from Micheal Ernest and others to one of the questions i raised in the forum.

------------------
Regards,
Shree
[This message has been edited by shree vijay (edited December 11, 2000).]
[This message has been edited by shree vijay (edited December 12, 2000).]

[naveen sahu]

Originally posted by shree vijay:
<code>
class guitar{
private String play(){return "rock";}
public String go() { return play(); }
}
class ibanez extends guitar{
String play(){return "metal";}
}
class music {
public static void main(String s[]){
guitar g=new ibanez();
System.out.println(g.go());
}
}
</code>

Hi, i think i can get a bit.
When the compiler compiles a program, it checks whether the method you call is accessible.
Consider the assignment
guitar g = new ibanez();
and then,
g.go()
when the compiler sees g.go() it checks the type of the variable g. The type of the variable g is guitar. And the go() method is of course available in the class guitar. So, it compiles fine.
But when the program is run, then what really matters is the type of the object you have assigned to the reference, not the type of the reference. Here the type of the object in memory for the reference g is ibanez. Now the question, is does ibanez class have the go method? Yes, it does, because it inherits it from the base guitar. So, the method call to the base class method is issued. Now, the go() method calls the play() method of guitar. (This is the case of the private play() called by the other member method go() which is perfectly legal)
Therefore, the output is 'Rock'

I think the question of the Nasir is about dynamic method dispatching mechanism (dynamic method lookup)and probabely he wants to know , that why the mehod play() available in the guitar() executed instead of play method available in ibanez class.
according to Nasir expectations the play() method of class ibanez should be executed, and when he see that the method of base class is executing then he post this question and wants to know that when , which method will be called if available in both the classes (base & derived) like play() method available in both classes guitar & ibanez.
I can explain this thing in some other way let suppose java compiler is a director and he/she is going to direct a film/movie. here Nasir intrusted in the direction portion not in the screenplay (that what is going on the screen).
and Shree Vijay your explaination just giving screenplay
that what is going on step by step. but the question is
why the director(java compiler) has choosen a particular step 2(play() from guitar) after a particular 1(after calling go()) step and why not the step 3 (play() from ibanez).
(the questions ambiguity reside in the above statement)
in java technical terms the question should be posted as
why in the above given code play() method of guitar class executed and why not of ibanez class ( while both classes are linked with hierarchy and having method with same signature).
Am i right Nasir ?

[eric moon]

>>>>>>Here the type of the object in memory for the reference g is ibanez. Now the question, is does ibanez class have the go method? Yes, it does, because it inherits it from the base guitar. So, the method call to the base class method is issued. Now, the go() method calls the play() method of guitar.<<<<<<
So java has "forgotten" that the object in memory is an ibanez, once it's made a call to the parent method go()?? It's still an ibanez, I would have thought its class would get checked everytime a method was performed on it....I mean, you are calling the go() method of guitar, but you're still calling it on an ibanez. I would expect to get "metal".
Is this considered a deficit or a feature??? Is there a reason you wouldn't want this behavior??

[eric moon]

>>>>>>>>>(This is the case of the private play() called by the other member method go() which is perfectly legal)<<<<<<<<<
To continue: would I get "metal" if play() wasn't private?? Or is this a red herring?

[Poornima Shetty]

Hi Eric,
As you said you would get a result of "metal" when you change the access modifier of play() method in the guitar class to friendly in which case the g.go() will invoke the play() method in the ibanez class thereby printing metal as the output.
The code is as below:
class guitar
{
String play()
{
return "rock";
}
public String go()
{
return play();
}
}
class ibanez extends guitar
{
String play()
{
return "metal";
}
}
class music
{
public static void main(String s[])
{
guitar g=new ibanez();
System.out.println(g.go());
}
}
Hope this helps you..
Regards,
Poornima,

[Panagiotis Varlagas]

Were the play() method in the Guitar class non-private, the outcome would be "metal", isn't it so?
Thanks,
Panagiotis.

[Nasir Khan]

Thanks all of you for detailed explaination.
The class of the object may not be known at compile-time . The runtime system identifies the actual class of an object and
invokes any overriding method of that class.In my example since play() method of class guitar is private ,class ibanez is
not overriding it but defining its own separate method .The outcome of 'rock' implies that calls to private methods are
resolved at compile time and not subject to dynamic method lookup. (correct me if I'm wrong here).I think same situation
occurs if the overriden and overriding
methods are static because static methods infact can't be overriden as well.
Well,that is all I extracted from above explainations that isn't final declartion if i'm wrong anywhere let me know
Thanks


[This message has been edited by Nasir Khan (edited December 12, 2000).]