viktor.klang at gmail.com
Mon Oct 3 13:20:22 EDT 2011
On Mon, Oct 3, 2011 at 6:36 PM, Kasper Nielsen <kasper at kav.dk> wrote:
> 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.
I'm also a fan of pragmatic design, but not when it comes to standard
libraries, simply because you cannot revert later. Pragmatism thrives in
dynamic environments, a standard lib is usually anything but dynamic.
java.util.Date was also a rather pragmatic approach.
> Adding 1 interface is better then adding 2.
According to what definition of "better"? To be honest, if we'd have more
fine grained interfaces in Java, we would probably not be in this situation
we are in today, where the Collection interface is so broad you oftentimes
have to choose between performance or add UnsupportedOperationExceptions.
If we'd have more fine-grained interfaces (or typeclasses) we could be more
selective in what data gets exposed.
> Look, you probably have a pretty specific use case for why you cannot use
> the equals contract when you remove an element.
In my world equality is contextual, having equals on java.lang.Object
removes the possibility of contexts. Universal equality is one of those
things where there jury is still out.
> And you have no need for a custom hash code.
And so I should not have to tinker with that. So the simplest 2 solutions
1) Separate the things into Hashable and Equivalence, if it is deemed that
euqality is always interesting when dealing with hashes, then Hashable
should extend Equivalence. All is fine.
2) Atleast make it so that it doesn't create pointless boilerplate and make
Equivalence an abstract class (due to the lack of mixins in Java) and have
the default implementation of hash return a.hashCode()
> 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.
I'd be more than surprised to see hashCode being called at all places where
equality is checked. Atleast in Java. The other way around is probably true
tho, that when you need Hashability, you need Equality, this ties into what
I've said previously in this email.
> Because you need both most of the time.
I do not believe that. Equality as a concept I believe is far more used than
hashability. If you do not believe me we can have a small contest to see who
finds most usage of either equality alone or equality and hashability in a
randomly chosen Java project.
> 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.
And since the majority of Java classes have mutable state, the majority of
them is broken.
> I mean forcing you and a handful other people to also implement
> Equivalence.hashCode() method is not going to ruin anyone's day.
Boilerplate ruins my day, I think it's rude to the users.
> 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.
Indeed! See my answers above.
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest