Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Message-ID: <001901c3096d$b4f3fd00$fe78a8c0@peter>
From: Peter_Kossek@t-online.de (=?iso-8859-1?Q?Peter_Ko=DFek?=)
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
References: <000001c308d3$bbcf6a00$0100a8c0@freefall>
Subject: Re: [collections] testing equality with some Comparator
Date: Wed, 23 Apr 2003 09:55:27 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Mischa.

I agree to your idea of different functions of equality, so I followed this
discussion with interest. Quite often I have made the experience that
programmers were quarreling about the best equals method for an object, or
worse, one programmer had to work around an inadequate equals method another
programmer had made long before. I think it is better to encapsulate what people
think about equality. E.g., if we have a person object with the variables
'int_id', 'name' and 'address', one user interface programmer will say:
'Equality is the equality of the content, I don't care about that id value'. A
database programmer might say: 'Two objects are equal if they have the same id,
nothing else can be important.' The best way to separate the concerns of these
two people is to create two Person classes for each access level, and to use a
tranformer function, so that each programmer can realize the equals function
he/she dreams about. But we can't always create an own object model for each
application level, can't we? Performance issues and organizational problems
might stop our efforts to build up one level after the other. So it is a good
idea to allow each developer to create an idea of equality for one moment.

I can't solve the problems you realized in your last posting, but I want to add
some thoughts.

1.
> I think you are right with the BinaryPredicate instead of a
> Comparator, since I am only interested in defining an alternative
> equivalence between the elements in the collection, not in some order.

That's right, but the Comparator is the well known mechanism of Java to create
an alternative equality function. People who want to make an equals function
shouldn't have to learn a new class. I would suggest to have an API that easily
allows to use Comparator instances as parameters here.

2.
> The method above as well the alternative implemenation using functors
> don't only require the elements to match, but also to appear in the same
> order. (...) I also want c1 and c2 to be equal to c3 = [(12, alice, another
street),
(11, john, a street)]. This could be solved by sorting, but then we do
> need the Comparator.

In the Java core, java.util.AbstractCollection doesn't define equals, but
AbstractSet and AbstractList do. So it is not easy to be totally compatible to
the core. I would suggest to implement the behavior of AbstractSet.equals, which
says two sets are equal iff they have the same size and each element of one set
is contained in the other. We need a helper method #contains(Collection, Object,
Comparator) or #contains(Collection, Object, BinaryPredicate) here. To be faster
for lists, I wouldn't use the same algorithm to compare two lists. If two lists
are compared, the order of the elements should be considered.

-Peter