commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <>
Subject RE: [functor] predicates
Date Mon, 28 Apr 2003 22:54:21 GMT
On Mon, 28 Apr 2003, Jason Horman wrote:

> Ok, I see. I would think though that using these predicates with lists would
> be very common, and the currying technique is a little cumbersome. Maybe the
> addition of a static function in each predicate that would return the right
> bound version of the same would be useful.
> inner class: new IsLessThan.RightBound(new Integer(7));
> or
> static method: IsLessThan.bindRight(new Integer(7));
> or
> unary and binary predicate (internally right bound): new IsLessThan(new
> Integer(7));
> Just a thought. It just seems like one of the goals of functors is to reduce
> code and side effects, thereby reducing errors. [...]

Agreed.  Another goal is to build complex behaviors by composing trivially
simple things.  Separating the [Binary]IsLessThan predicate from the
mechanism for creating a UnaryPredicate out of a BinaryPredicate and some
constant value is in line with that.

> [...] Saving the isLessThan
> predicate and then using it in the select introduces a side effect. I would
> prefer to do more of the work in line.
>, new IsLessThan(7));
>, new
> IsLessThan.RightBound(7));
> IsLessThan.rightBind(7));

Agreed, I broke them out for readablity in email.  In practice I'd create
isLessThan7 inline:
    new RightBoundPredicate(
      new Integer(7)

(unless I had some need to reference isLessThan7 mutliple times, I

> Actually, in the interest of reducing keystrokes something like this might
> work.
>   // returns unary right bound version of IsLessThan
>   Is.lessThan(new Integer(7));
>   // returns binary version of IsLessThan
>   Is.lessThan();
> Where "Is" is a factory for "Is" predicates.
> Is.lessThan
> Is.greaterThan
> Is.equal
> Is.nul
> Is...
> It would be nice to get rid of all of the "new" declarations in the usage of
> functors.

I'm OK with static methods that hide the "new" invocation from you, as
long as the public constructor is still available.  A global "Is"
factory seems like it pulls together a bunch of types unnecessarily (and
creates an artifical distinction between classes declared in the same
component as Is and those that aren't).  Why not simply put the factory
method in the type being created (like the existing
RightBoundPredicate.bind())?  I'm also ok with some sort of
<ComparisonPredicate>.rightBound(Object) method as long as it's similiarly
derived from a common BindRightPredicate adapter (as opposed to recreating
the "bind the right argument of this binary function to the given
constant" functionality in multiple packages or types.)

- Rod <>

> -jason

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message