On Oct 19, 4:01 am, Reinier Zwitserloot <[email protected]> wrote:
> I guess search in PDF is broken.
>
> The equals contract, nor any other, stipulate that you need to adhere
> to Liskov. They do, however, stipulate the transitive, reflexive,
> symmetric rule. The suggested equals implementation is broken in that
> regard. Josh is a mortal, and therefore fallible. Nevertheless it only
Sorry to split hairs here, but it is not broken! It works perfectly
fine unless someone that do not understand the class goes on to extend
it in an incompatible way. This does not make the original
implementation broken. By the same token I could say that getClass() !
= other.getClass() is broken since I cannot make a simple subclass and
have the class hierarchy work properly with regards to equals. Say I
extend a Point2D class with some unimportant attribute, e.g. colour:
public ColouredPoint2D extends Point2D {
int getColour() {...}
}
Now if I thought that Point2D used instanceof in the superclass, I
would expect a red (2,2) point to be equal to a blue (2,2) point, but
this is not the case!
The approaches are not inherently broken, but has different trade-
offs. The message continues to be that you cannot override the
equals() method without understanding the class hierarchy's use of
it.
Kind regards,
Jacob Grydholt
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
