On Sat, Apr 12, 2014 at 3:18 PM, Thomas Neidhart <thomas.neidh...@gmail.com>wrote:
> On 04/12/2014 08:41 AM, Dipanjan Laha wrote: > > 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 > > I agree that we can not change it like that as it would potentially > break existing code. > > Otoh, I do not think the problem at hand is directly related to the one > stated by Joshua Bloch, as in this case we do not add additional values > or necessarily deal with sub-classes. > > The problem comes from the fact that different collection classes do > different types of equality checks, and even further restrict their > equals method to specific types of collections. > > This issue was already reported a while ago after executing similar > automated tests on collections (probably even with the same tool). At > the time I decided to ignore it, which was probably a mistake. So I > would suggest that we at least document what the equals method of the > respective decorators actually does, with a link to the mentioned > CollectionUtils method if one wants to be sure to do a real value > comparison. > Imho, that would be the right path to take now. So should we create a new issue with this? -Dipanjan > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
