kasper at kav.dk
Mon Oct 3 12:36:59 EDT 2011
On 03-10-2011 18:04, √iktor Ҡlang wrote:
> I really do not see practically reason for separating these into 2
> different interfaces. Only more clutter.
> You're a firm disbeliever is the Single Responsibility Principle?
No, I am a firm believer in pragmatic design and keeping things simple.
Adding 1 interface is better then adding 2.
Look, you probably have a pretty specific use case for why you cannot
use the equals contract when you remove an element. And you have no need
for a custom hash code.
But I think for most other people there is no need to separate the
responsibility of calculating a hash code and answering whether two
object are considered equivalent. Because you need both most of the time.
One of the first things you learn when working with Java is always
override hashCode() if you override equals(). I think it is only natural
that any interface defining custom policies with regards to equals() or
hashCode() supports that notion.
I mean forcing you and a handful other people to also implement
Equivalence.hashCode() method is not going to ruin anyone's day.
> See also
> which supports user-defined equivalence comparisons.
> That is about the equivalence of the Keys, not of the Values.
If you look closer it also support value equivalence.
More information about the Concurrency-interest