Equator interface

Java has Comparable and Comparator to compare objects. 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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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 So, if
anyone wants to give that a go feel free!

Stephen


To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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.
- 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
() and Code() 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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

Stephen Colebourne wrote:
BTW, I favour trying to create a 'FlexiMap' map implementation, which
has pluggable 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 () 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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org