What are we comparing in equals(other) ?

Hi there... Since you asked about the compareTo method I am assuming you have done the Treet.java course in your workspace. So I will just take an example from that code, sorry in advance if my assumption is wrong. :

@Override
  public int compareTo(Object obj) {
    //2-3: this will create interface to compare treets based on date it has.
    Treet other = (Treet) obj; //2-3: learn more about this casting
    if (equals(other)) {
      return 0; //2-3: means if the object casted is the same as the object compared return 0
    }
    int dateCmp = mCreationDate.compareTo(other.mCreationDate);//2-3:compare by creation date
    if (dateCmp == 0) {//2-3: if the date of creation is the same we will compare the description:
      return mDescription.compareTo(other.mDescription);
    }
    //2-3: if the creation date is different then just return the difference:
    return dateCmp;
  }

What exactly are we comparing in that line ? We are comparing two objects derived from the class Treet. Yes the first object (let us called it the first object) is already declared as an instances object of Treet and has attributes like mDescription, mAuthor, and mCreationDate. The other one (let us called it as second object) at the moment still unknown thus we just using the safest assumption that it is an object therefore it is derived from Object class. Please note that only the instances of Treets that has the access of attributes mDescription, mAuthor, and mCreationDate.

What parameters are being compared? To be able to compare the first object (which is a Treet) and the second object (which is currently only known as an Object not yet a Treet) we need to have the same attributes to compare to (mDescription, mAuthor, mCreationDate). To really proof that two objects (first and the second) is really actually one same object you need to access all of those attributes. This is what is being compared for equals right here. It is the same for human right in order to proof that two men are actually one same person you need to compare all attributes (height, weight, date of birth, real name and so on.).

*In another thread someone answered that this instance of the received object is being compared to our class object. Wouldn't that always return 0 assuming we downcasted it? *

Nope, downcasting is not like you copied and object with all attributes and values and pasted into another object. It is only declaring that the second object still unknown is an actually a Treet. Therefore the compiler should treat the second object the same as other Treet objects and expect it has (mDescription, mAuthor, mCreationDate) but the value of those attributes may vary from the first Treet. So why you need to do this? Can the Java compiler check if it has mDescription, mAuthor, mCreationDate attributes are in the second object or not? Therefore we do not need to hassle ourselves with casting it first, right?

The answer is unfortunately, no.... let us just say compiler is a strict partner that will only do something if all requirement is met. But compiler has a good reason to do so, checking uncertain things all over the source code is wasting of time and energy (in this case computing resources). So you need to talk your way through with the compiler, nicely like:

Compiler: what do you want? (it is being strict)

You: Yeah, you know the second object that we are talking about, the one that only known as an object?

Compiler: Yeah, what about it?

You: well, here is the thing... I know for sure it is actually a Treet, you know the one object that has mDescription, mAuthor, mCreationDate? So can you just ask that second object the values of those three attributes so I can make sure that first and second object is the same equals or not?

Compiler: I can do that, BUT you need to fill in casting code in your source code. It is like iron clad agreement that you guarantee that indeed that second object is a Treet. Otherwise, you know what the consequences if it is not actually a Treet right?

You: Yeah kinda,... you will get mad, telling me I am lying or at least stupid for making wrong assumption, get stuck and stop all things you do for me, and serve me with run time exception,.... anything else?

Compiler: well good if you know that. Now please proceed by writing the casting code to the intended object.

Sorry for the bad screenwriting, but that is what happen when you cast an object. So by casting you just make the compiler to treat the unknown object as if it is a Treet. Gathering information about who is the author, what is the description and when it is being made. Then using that information you compare it to the first Treet object to see if and only if all three information are exactly the same to declare they are equal.

what is the purpose of that comparison? The purpose is if both objects are equals meaning you do not need to process to the next comparing things such as mCreationDate and if it is the same value you need to compare description alphabetically.

But why is it a big deal whether I go to the next level or not? The computer is smart it can calculate the difference between all attributes and will still return zero of all attributes. Well the answer is, computer is only good at calculating but not sorting. In the end this compareTo method actually will be used to sort all treets by its creation date right? Therefore the compiler will have to slide many treets up and downs based on the difference from the base treets. This work of sorting which looks super easy for human actually a resource intensive for computers. It creates many loops of processes so if you can determine that two objects are equal you can put it just side by side right? If one object has to move because its rank in the sorting list is changing the other object will just follow along and move along.

Sorry for the long explanation. I hope this can help