[Collections] Equator interface

[Stephen Kestle <st...@orionhealth.com>]

Java has Comparable and Comparator to compare objects.  Object has an 
equals() method.  But what are we meant to do when and object has 
multiple ways of being equal?

Consider an database row that has a name, code and a value.  Equality 
could be based on

    * database id
    * code
    * name and code
    * case-insensitive name

Any of these could be appropriate in different situations - in the same 
way we use Comparators, we should be able to use Equators.

When extended to collections, this allows us to search for specific 
values (with an EqualsPredicate that takes an Equator), and implement 
Maps and Sets that use specific equators to determine uniqueness (a 
HashEquator interface may also be defined for this).

However, it is also useful for general coding and equality checking.  
Does this mean it's suitable for Lang (not really knowing anything about 
that project)?  Is there a Predicate class in Lang?

If an Equator is determined to be something worthwhile for the next 
(generic) version of Collections, I can provide interfaces, default 
implementations tests etc.

Cheers

Stephen Kestle


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Collections] Equator interface (methods)

[Stephen Kestle <st...@orionhealth.com>]

Stephen Colebourne wrote:
> Stephen Kestle wrote:
>> If an Equator is determined to be something worthwhile for the next 
>> (generic) version of Collections, I can provide interfaces, default 
>> implementations tests etc.
>
> I certainly think that there are multiple ways to to equals checks. In 
> my day job we compare by ==, equals and id.
>
> Done well, this would make a good enhancement in the 'new' collections.
Ok - having got some positive feedback, I will go on to the first issue: 
the Equator interface design.

I propose two methods: one for equality checking, and another for hash 
codes.  This ensures that when used, the general contract of 
Object.equals() and Object.hashCode() are followed in a similar fashion.

There is also the problem of naming here - what should the methods be 
called?  We want it to read well, so we'll start by listing the java 
equals and compare methods.  Summary of the rest of the post: I prefer 
boolean equate() and int hash().

if ( object1.equals(object2) )
    "if object1 equals object2 then..." - pretty simple

if ( object1.compareTo(object2) > 1 )
    "if object1 compare to object2 is greater than 1 then..." - 
"compared to" would make more sense in a sentence, but we favour active 
tenses, since methods are an instruction on an object.  Probably better 
is to phrase it like:
    "if (object1: compare [yourself] to object2) is greater than 1 then..."

if ( comparator.compare(object1, object2) > 1 )
    "if (comparator: compare object1 and object2) is greater than 1 then..."

Getting hash out of the way is easy: hash().  But what's the correct 
verb for equality?

if ( equator.equate(object1, object2) )
    "if (equator: equate object1 and object2) then..." - I prefer this 
one at the moment

if ( equator.equalTo(object1, object2) )
    "if (equator: is object1 equal to object2) then ..." - I have this 
at the moment, but it requires reshuffling of the sentence.

So this post is a bit verbose, but naming is one of the most important 
tasks of development, and since this is rather foundational...

Cheers

Stephen (K)


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Collections] Equator interface (and FlexiMap)

[Stephen Kestle <st...@orionhealth.com>]

Stephen Colebourne wrote:
> BTW, I favour trying to create a 'FlexiMap' map implementation, which 
> has pluggable hashcode/equals/weakReference/softReference/... So, if 
> anyone wants to give that a go feel free!
>
> Stephen
In my current code, I have an Equator (equalTo()) method, and a 
HashEquator (extends Equator and adds a hash() method), but now that 
I've gone and implemented stuff, it comes down to the fact that nothing 
uses Equator directly, because so many things use hash codes etc, that 
you're just shooting yourself in the foot later by not following a 
similar contract to the Object.equals() method.  Thus there will only be 
one plug for hashcode/equals implementation (hopefully just clarifying 
what you were thinking).

What I also was going to say is that you can use an EquatorMap and 
ReferenceMap to decorate each other, but they're going to extend from 
different classes, so that's no good.

So, are you talking about one Map to rule them all?  Sounds convenient.

Stephen (not C :)


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Collections] Equator interface

[Stephen Colebourne <sc...@btopenworld.com>]

Stephen Kestle wrote:
> If an Equator is determined to be something worthwhile for the next 
> (generic) version of Collections, I can provide interfaces, default 
> implementations tests etc.

I certainly think that there are multiple ways to to equals checks. In 
my day job we compare by ==, equals and id.

Done well, this would make a good enhancement in the 'new' collections.

BTW, I favour trying to create a 'FlexiMap' map implementation, which 
has pluggable hashcode/equals/weakReference/softReference/... So, if 
anyone wants to give that a go feel free!

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org