Re: noob question: string comparing

"David Segall" <david@address.invalid> wrote in message
news:9i8sc2hagqtk2a2pni84nnbjhbiucjvfce@4ax.com...


    I don't think the wallet is the greatest example, but you could imagine
that your wallet and Eric's wallet are identical in every respect (colour,
number of protons, electrons and neutrons that compose it, etc.), but the
two wallets are still distinct.

    Maybe this example will be better:

    Alice and Bob are speaking:

Alice: "I'm thinking of a specific friend."
Bob: "I too am thinking of a specific friend."
Alice: "My friend is 28 years old."
Bob: "My friend is also 28 years old."
Alice: "My friend has brown eyes, blond hair."
Bob: "Mine too."
Alice: "My friend's name is Charlie."
Bob: "So is mine!"
[etc. This goes on, Alice listing a whole bunch of attributes about her
friend, and Bob saying those same attributes apply to his friend.]

    So, are Alice and Bob thinking about the same person? It might be, or it
might not be. It's possible that they are speaking about two completely
different people who are remarkably similar, or it might be that they are in
fact speaking about the exact same person, not knowing that they had a
common friend.

Alice: "Well, my friend Charlie's cell phone number is 12345678901."
Bob: "Oh, well I don't know what my Charlie's cell phone number is. However,
his house number is 19876543210."
Alice: "Hmm, I don't know what my friend's Charlie's home number is."

    Just like a person can have multiple phone numbers, so can objects in
Java have multiple references pointing to them. The fact that you have two
different references doesn't nescessarily mean you have two different
objects!

Alice: "Well, my friend Charlie lives alone at 22 Baker Street."
Bob: "Ah, so does mine. So we must be talking about the same person."

    One way to think of it is that references are sort of like pointers
which hold the address of the objects they are refering to. When you use the
== operator on two reference, it's comparing the addresses that each
reference points to, to see if they are identical. When you invoke the
..equals() method, you're invoking it on a specific object, and that method
is free to do anything the programmer designed it to do. In fact, it can
even "lie" to you and return false when you check if an object is equal to
itself, or it can be programmed to erase all the files on your haddrive,
etc.

    Usually, you assume that the programmer who wrote the equals is not
malicious, and you can just read the documentation for the equals() method
to find out exactly how it determines equality between two objects, or
failing that, read the source code itself.


    I think this "assigning a default property (.value) to a String object"
explanation may be very misleading. The JVM never creates fields out of
nowhere. If a object has a field, it's because the class that defines that
object declared the field. If you look at the source code for the String
class, it actually has 4 fields:

    private final char value[];
    private final int offset;
    private final int count;
    private int hash;

If you check the source code for the equals() method in String, you'll see
it essentially does a character-by-character scan from value[offset] to
value[offset + count - 1] to check if two string objects are equal. So it's
possible that two String object have completely different field values, but
are evaluated to be equal! For example if the two String's field values are:

StringOne {
  value[] = {'A', 'B', 'C', '1', '2', '3'}
  offset = 3;
  count = 3;
  hash = 42;
}

and

StringTwo {
  value[] {'1', '2', '3', 'X', 'Y', 'Z'}
  offset = 0;
  count = 3;
  hash = 69;
}

StringOne.equals(StringTwo) would return true, because of the way it's
programmed.


    I think what you were missing was the fact that the .equals() method can
be programmed to do anything the programmer wishes.

    - Oliver