Why use Objectg in Equals method?

[pek]

Recently I've been thinking about the equals method a lot. I am
reading Effective Java and there is an item that talks about the
equals method. Several questions came to my mind, like Why compare a
class with it's superlcass? (http://groups.google.com/group/
comp.lang.java.programmer/browse_thread/thread/01c79dc569d1a480) and
others.

Another question I have is:

Why use Object as a parameter in the equals method?

Why don't just narrow it down as much as possible? If I have a Point
class, why not use public boolean equals(Point p); ? Not only will
this make the method easier to create, it will avoid comparing
superclasses (but not subclasses). After all, for most of the cases, I
will compare an object with another object of the same class anyway.

Of course, if you intend to compare with objects of different classes,
this would be irrelevant. But, how many times do you do that anyway?

Thank you,
Panagiotis

 

[pek]

'equals()' is a public method of the primordial 'Object' class.

That means one can count on every subclass of 'Object' to have that method.

A method with different parameters, e.g., 'equals( Point p )', would not
override the 'Object#equals()' method.  That would cause problems with code
that depends on 'equals()' to be overridden.

Hmm.. Point taken.. Didn't think of overriding the equals method... I
completely forgot about it.

It is convenient that 'equals( Object o )' is an override - it allows for
expressive compactness in a ton of algorithms, e.g., those on which
collections classes rely.  If one built, say, a 'Set' without overriding
'equals()', then the 'Set' behavior would be different from that which is desired.

Correct, but in this example, you know that you will be comparing
different classes. I was talking more about situations that you
wouldn't, although I do understand now.
Thank you,
Panagiotis

 

[Mark Space]

[**] I understand there's work afoot to "reify" generics,
but as far as I know it hasn't borne fruit yet.

There are reified classes in the Java API now. Static methods in
Collections will make runtime typesafe Collections, Lists, Maps and
Sets. They do it just by storing the class type you specify, and then
testing each operation to make certain it's of the correct type.

But that's an API feature, not a language feature.


static
<E> Collection<E>
checkedCollection(Collection<E> c, Class<E> type)
Returns a dynamically typesafe view of the specified collection.
static
<E> List<E>
checkedList(List<E> list, Class<E> type)
Returns a dynamically typesafe view of the specified list.
static
<K,V> Map<K,V>
checkedMap(Map<K,V> m, Class<K> keyType, Class<V> valueType)
Returns a dynamically typesafe view of the specified map.
static
<E> Set<E>
checkedSet(Set<E> s, Class<E> type)
Returns a dynamically typesafe view of the specified set.
static
<K,V> SortedMap<K,V>
checkedSortedMap(SortedMap<K,V> m, Class<K> keyType, Class<V> valueType)
Returns a dynamically typesafe view of the specified sorted map.
static
<E> SortedSet<E>
checkedSortedSet(SortedSet<E> s, Class<E> type)
Returns a dynamically typesafe view of the specified sorted set.

 

[Joshua Cranmer]

[**] I understand there's work afoot to "reify" generics,
but as far as I know it hasn't borne fruit yet.

There are reified classes in the Java API now. Static methods in
Collections will make runtime typesafe Collections, Lists, Maps and
Sets. They do it just by storing the class type you specify, and then
testing each operation to make certain it's of the correct type.

But that's an API feature, not a language feature.

Not quite. The proposals in question would do stuff like make new T[10]
or instanceof T legal, as well as (possibly) new T(). In short, moving
the reflection hacks to bytecode instructions.