On 16 Aug 00, at 0:48, Juha Lindfors wrote:
>
> Hi,
>
> At 16:55 15.8.2000 -0400, you wrote:
> >Object's default implementations of hashCode and equals compare
> >the object instance (i.e. the "memory location") without regard to
> >semantics (i.e. the meaning of the object). In other words,
> >person1pk will not always equal person1pk, if these are different
> >instances of the same key.
>
> What I was trying to get at was that I don't see a way the container can
> determine that the semantics of the said two methods are meaningful in
> order to refuse deployment. We can determine that the contract is correct,
> that equals() is reflexive, symmetric and transitive and within a
> reasonable doubt even consistent. But the Object's default implementation
> fulfills this contract as well -- and it's not considered "suitable".
>
> So my question still remains, how do we define a suitable implementation
> for these methods in order to reject the non-suitable ones?
Ah. Now I get it.
I suggest that we deploy any entity whose primary key overrides
both methods (assuming it passes all other tests), and refuse to
deploy any entity whose primary key fails to override either.
I believe that providing a more complete "suitability" test would be
difficult beyond any value that it had.
-Dan
>
> -- Juha
>
>
>
>
