• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

misunderstanding in K&B book

 
Lucas Smith
Ranch Hand
Posts: 808
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • 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
 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • 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
  • Quote
  • Report post to moderator
So "this" not always apply to currently executing object.
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • 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
  • 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
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • 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
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15216
36
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • 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
  • 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
  • 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.
 
Henry Wong
author
Marshal
Pie
Posts: 21021
78
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • 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
  • 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
Marshal
Pie
Posts: 21021
78
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • 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
 
Ninad Kulkarni
Ranch Hand
Posts: 802
Hibernate Linux Spring
  • Mark post as helpful
  • send pies
  • 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
  • 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
Marshal
Pie
Posts: 21021
78
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • 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: 802
Hibernate Linux Spring
  • Mark post as helpful
  • send pies
  • 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"
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic