commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jaka...@reider.net
Subject Re: [collections] predicate algebra
Date Tue, 07 Jun 2005 16:47:00 GMT
Stephen,

Thanks. If it influences your opinion any, I had envisoned the and()
et al as instance methods to predicate instances rather than static
methods.

Besides the readability, the implementation hiding also seems nice,
for example as implementation detail, the operators could just be done
inline instead of new classes,  eg:

// untested
public boolean and(p2) {
   return new Predicate(){ 
      public boolean evaluate(Object input){
         return this.evaluate(input) && p2.evaluate(input);}}}

et al

-Alan Reider


On 6/6/05, Stephen Colebourne
<scolebourne*btopenworld.com*jakarta*reider.net*7BF*so85*3@reply.e4ward.com>
wrote:
> This was suggested a long time ago, but never pursued. Personally, I
> dislike calling static methods on instances just because it makes the
> code 'read more easily'.
> 
> The [collections] functor code (including predicates) is intended to be
> a useful default set of classes for using predicates, not a
> full-featured functor system. The dormant [functor] project in the
> sandbox tackles that goal.
> 
> Thus as present I would be -1 to adding static methods as you propose.
> 
> Stephen
> 
> 
> jakarta@reider.net wrote:
> > Would it make implementation sense for predicates to extend a common
> > class (ConcretePredicate, PredicateImpl or some such)?
> >
> > Then one could conceivably write eg "predicate1.and(predicate2)"
> > in place of "new AndPredicate(predicate1,predicate2)".
> >
> > and other relational operators, eg andNot defined in the root class.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
>

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


Mime
View raw message