• 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

misunderstanding in K&B book

 
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is the sentence in K&B book on the page of 55:
"The keyword this always, always, always refers to the object currently running".

So what about that:


The output: 0
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's because instance variables do not take part in polymorphism.

You create an instance of Cast, which calls the get method implemented in Tree which then uses it's copy of the x var.

If you override get in Cast and output x, it will return 10.
 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So "this" not always apply to currently executing object.
 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're confusing yourself by using the variable x in two places. Change the names of the two variables and it will make more sense.

Using a more defined method name, rather than a generic get might make it easier to follow as well.

Variables don't get overridden, they get 'shadowed.' It's the shadowing that is causing confusion.

Look at the following code. From Java's point of view, there is no difference. Why would you expect the getZero method in this code to return anything other than 0? (Assuming it compiles. I didn't compile it.)




-Cameron McKenzie
 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Cameron Wallace McKenzie wrote:
Variables don't get overridden, they get 'shadowed.' It's the shadowing that is causing confusion.


In this case the variable is hidden, not shadowed.
 
Cameron Wallace McKenzie
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
See!!! It's even confusing me!

Two variables that are part of the same class with the same variable name is confusing, regardless of which label gets affixed to it.

-Cameron McKenzie
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, you have a class Cast which extends class Tree. Now in line 6 you create a new Cast object, and in line 7 you call the get() method on that object. In line 13 you access the variable x of the object via the 'this' reference.

Note that there is only one object - the object to which 'c' refers. The 'this' reference in line 13 refers to the same object that 'c' refers to in lines 6 and 7.

Don't confuse 'object' and 'class'.
 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Cameron Wallace McKenzie wrote:See!!! It's even confusing me!

Two variables that are part of the same class with the same variable name is confusing, regardless of which label gets affixed to it.

-Cameron McKenzie


But the confusing situations are the spirit of the exam
 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesper Young wrote:The 'this' reference in line 13 refers to the same object that 'c' refers to in lines 6 and 7.


So why does it print 0 instead of 10? The visible x is that contains the value of 10. The x from tree is hidden.
 
author
Posts: 23951
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

Lukas Smith wrote:

Jesper Young wrote:The 'this' reference in line 13 refers to the same object that 'c' refers to in lines 6 and 7.


So why does it print 0 instead of 10? The visible x is that contains the value of 10. The x from tree is hidden.



Hidden doesn't mean that it is not accessible -- as you have seen with this example. Your get() method uses the "hidden" x variable -- as the first responder to this topic mentioned, "instance variables do not take part in polymorphism".

Henry
 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So there should be:
"The keyword "this" always, always, always refers to the object currently running when polymorphism works."
Am I wrong?
 
Henry Wong
author
Posts: 23951
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

Lukas Smith wrote:So there should be:
"The keyword "this" always, always, always refers to the object currently running when polymorphism works."
Am I wrong?



The "this" variable does refer to the object whose instance method is being called. This fact doesn't change just because you disagree with how Java implements polymorphism.

If you don't believe this, simply store a copy of the Cast variable somewhere. Then if you modify the get() variable to access the variable, you'll see that it is the same instance.

Henry
 
Ranch Hand
Posts: 814
Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Here the nearest scope of x is tree class not cast class. Java choose always nearest scope.
Correct me if I am wrong.
 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ninad Kulkarni wrote:

Here the nearest scope of x is tree class not cast class. Java choose always nearest scope.
Correct me if I am wrong.



Here the nearest scope of x is tree class not cast class. Java choose always nearest scope. - that would explain everything
 
Henry Wong
author
Posts: 23951
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

Ninad Kulkarni wrote:
Here the nearest scope of x is tree class not cast class. Java choose always nearest scope.
Correct me if I am wrong.



This is not a case of two variables being in scope, and java choosing the one that is "nearest scope" (quotes because it is not an official term).

The x variable (of the cast class) is *not* in scope to the get() method. Period. To prove this, you can move the other x variable "really far away", and you will see, that it will not access the x variable in the cast class.



Henry
 
Ninad Kulkarni
Ranch Hand
Posts: 814
Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The x variable (of the cast class) is *not* in scope to the get() method.



You are absolutely correct Henry.
Thanks for such a nice explaination. Now I will refer it as "The x variable (of the cast class) is *not* in scope to the get() method"
 
reply
    Bookmark Topic Watch Topic
  • New Topic