"equals" predicates

13 views
Skip to first unread message

kbwelker

unread,
Mar 1, 2012, 12:53:10 PM3/1/12
to Funcito
It seems like another "common" pattern of Function usage for filtering
would be to compare the equality of a method return value (i.e., a
POJO "getter") against a fixed value. So it might be nice to support
the production of a Predicate-like object (details depending on each
library), provided a method to be called, and a value to compare
against.

In Guava, this might entail using:
Predicates.compose( Predicates.equalTo(value), Function )

FJ does not have predicate class, but does have method requiring an
F<T,Boolean>, such as List.filter()

Jedi might involve either Filter2, or more likely EqualObjectFilter.

I'm thinking the approximate usage for any of these might look like:

Predicate p = equalsFor( callsTo(X.class).getVal, valToCompare );

kbwelker

unread,
Mar 10, 2012, 7:19:19 PM3/10/12
to Funcito
This might tie into the other thread I have on possibly defining a way
for operator shortcuts to be thrown in. While .equals() is not
technically an operator, the same principle might apply.
There were two proposed ops implmentations. The 1st was argument
based:

Predicate<X> p = predicateFor(callsTo(X.class).getYVal(),
FuncitoOps.equal(someYVal));

which in shorthand might read:

Predicate<X> p = predicateFor(callsToX.getYVal(), equal(someYVal));

Or the alternative fluent-API form might look like

Predicate<X> p = functionFor( callsToX.getYVal() ).equal(someYVal);

The fluent form has the advantage of never requiring the user to add
another static import to get the ops. The usage disadvantage is that
the user has to think in terms of a Function first in order to extract
the value to be compared with the op, before appending the fluent Op.
The implementation disadvantage is that I now need a return type that
extends Predicate but also implements my Ops.

Reply all
Reply to author
Forward
0 new messages