aspose file tools*
The moose likes Beginning Java and the fly likes not grasping the dot operator between objects... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "not grasping the dot operator between objects..." Watch "not grasping the dot operator between objects..." New topic
Author

not grasping the dot operator between objects...

Jesse Crockett
Ranch Hand

Joined: Feb 03, 2005
Posts: 129
Here is a trim version of the code I'm using, trying to get a better grasp of object assignment.



I understand that e1 and e are distinct, but I don't really understand the meaning of "e1.e". And also, if there were a second new Eco instantiation in main, "Eco e2 = new Eco()", then the first "Eco e" is abandoned, correct?

I put the equality tests in there just to show what I'm trying to learn. Both println's output "false", but is there a difference between "equals()" and "==" when testing? If so, how might I learn more about it?
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1824

The "." operator means that you are accessing a member (a variable or a method) of an object. In this case, you are accessing the member "e" of the object referred to by the variable "e1" (note that I didn't say that e1 is an object -- it isn't; it's a reference to an object. There's not a terrible distinction between the two for beginners or advanced java users, but as you go further down the road, the difference is important).

So the "." operator (the "dereferencing operator") accesses members. The line

works the same way. The "System" object is actually a class from which you are access the static object out. Then you access the println method on that object.

As far as .equals() vs. ==, the former is a logical equality while that latter is physical equality. (we could think of it as testing object equivalence vs. reference equivalence.) Consider:


We've created two different objects in lines 10 and 11 but they have the same value. So, in line 14 we get a true, because they are logically equal but in line 15 we get a false because they are physically different.

Now, in line 17 we create a new reference to the object we created in line 10. (See, we're already learning the difference between references an objects.) We havn't created a new object, just a new reference. Now, in line 19 we get a true becase an object is logically equal to itself and in line 20 we get a true because the two references refer to the same physical object.


Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19064
    
  40

Originally posted by Jesse Crockett:
Here is a trim version of the code I'm using, trying to get a better grasp of object assignment.

I understand that e1 and e are distinct, but I don't really understand the meaning of "e1.e". And also, if there were a second new Eco instantiation in main, "Eco e2 = new Eco()", then the first "Eco e" is abandoned, correct?

I put the equality tests in there just to show what I'm trying to learn. Both println's output "false", but is there a difference between "equals()" and "==" when testing? If so, how might I learn more about it?



This is really a bad example, in that the Eco class contains a reference to an Eco class. Not that this is a bad idea, it is just that it confuses things for a newbie. For example, if the constructor that did nothing didn't exist, you wouldn't be able to contruct an eco object, it would run out of memory due to the recursive contruction call.

From the main context, there is no "e" reference. There is an "e" reference, that is part of the "e1" object. That is why you need e1.e to reference that object. I have no idea what you mean by the "e" reference being abandoned.

In your case, there is no difference between "==" and equals(), but if you override the equals() method, you can introduce a difference.

Sorry for being so terse, but as I mentioned, I wished you picked a better example.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Jesse Crockett
Ranch Hand

Joined: Feb 03, 2005
Posts: 129
Thanks for clearing things up. About the example..

This is really a bad example, in that the Eco class contains a reference to an Eco class. Not that this is a bad idea, it is just that it confuses things for a newbie.


It's a problem pulled straight from the K&B SCJP 5 exam guide, thanks. And I wish you hadn't insulted my intelligence. Possibly what I meant, which an author should be capable of intuiting, is that the object referred to by e is abandoned after e is reassigned.
[ March 17, 2006: Message edited by: Jesse Crockett ]
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19064
    
  40

Possibly what I meant, which an author should be capable of intuiting, is that the object referred to by e is abandoned after e is reassigned.


If you did this in main...



You will assign "e1.e" to a new value, and hence, the previous "e1.e" will be eligible for garbage collection. If you did this in main...



Then nothing happens to "e1.e", as "e1.e" and "e2.e" are two different references.

Henry
Jesse Crockett
Ranch Hand

Joined: Feb 03, 2005
Posts: 129
do you mean that after "Eco e1 = new Eco()" in main, there is an implicit reference "e1.e" or something such, and that it is a distinct reference variable, distinct from either "e1" or "e", and refers to a unique object? I don't know what that would mean, because it sounds like "e1.e" is made of two objects... but, hey, I'm learning all the time.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19064
    
  40

Originally posted by Jesse Crockett:
do you mean that after "Eco e1 = new Eco()" in main, there is an implicit reference "e1.e" or something such, and that it is a distinct reference variable, distinct from either "e1" or "e", and refers to a unique object? I don't know what that would mean, because it sounds like "e1.e" is made of two objects... but, hey, I'm learning all the time.


From the context of the main() method, there is no "e" reference. There is only the "e1" reference, which points to an Eco object. This Eco object, has a reference to another Eco object, access via its "e" reference -- or "e1.e" to be exact.

Interestingly, the "e1.e" reference also has another "e" reference, accessed via "e1.e.e", but by the way it was constructed, it has a value of null.


Like I said, it is not really a good example for this. The Eco class has an internal reference to a Eco object, which it constructs, when you contruct an Eco object, using the default constructor.

Henry
Jesse Crockett
Ranch Hand

Joined: Feb 03, 2005
Posts: 129
Interestingly, the "e1.e" reference also has another "e" reference, accessed via "e1.e.e", but by the way it was constructed, it has a value of null.


That is interesting. Sure enough, "e1.e.e" prints "null". How might it be constructed in order to give it a value?


Is "e1.e.e" just the product of the instance declaration?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: not grasping the dot operator between objects...