commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dipanjan Laha <dipanja...@gmail.com>
Subject Re: Bugs in Apache commons collections, version 4.0
Date Sat, 12 Apr 2014 06:41:43 GMT
On Sat, Apr 12, 2014 at 1:04 AM, Thomas Neidhart
<thomas.neidhart@gmail.com>wrote:

> On 04/11/2014 05:52 AM, Dipanjan Laha wrote:
> > Hi,
> >
> > The only issue here is then Collection's equals implementation would need
> > to check individually whether the Collection also implements List, Set or
> > Bag (more such interfaces may come up in the future). This is kind of a
> > hard coupling between Collections equals and other implementations which
> > will become very difficult to maintain. The other option would be to fall
> > back to Object#equals (a lot of Java collection classes do that), but
> that
> > would mean that value based comparison won't be possible. Maybe there's a
> > better way to solve this, but I can't think of anything right now.
>
> usually the decorators delegate the call to equals to the decorated
> collection, which means we can not guarantee the symmetry requirement
> for all possible decorated collections.
>
> The only way to be on the safe-side would be to delegate to
> Object#equals().
>

If we do this, it would break a lot of existing functionality (and needless
to say tests).
Joshua Bloch says in Effective Java that "There is no way to extend an
instantiable class and add a value component while preserving the equals
contract, unless you are willing to forgo the benefits of object-oriented
abstraction" . So imho, I think we should let this be even if this breaks
equals symmetry

>
> A user can and should use CollectionUtils#isEqualCollection() for a full
> value-based equality check imho.
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message