On Sat, Apr 12, 2014 at 1:04 AM, Thomas Neidhart <thomas.neidh...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
