[collections] predicate algebra

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[collections] predicate algebra

jakarta-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] predicate algebra

Dakota Jack
Sorry that this is not helpful but I was surprised to see this
"predicate algebra".  Is this the first or second -order predicate
calculus with or without identify?  If so, I will be hornswaggled.  I
love that stuff.  Please let me know what this is all about.



On 6/3/05, [hidden email] <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] predicate algebra

Stephen Colebourne
In reply to this post by jakarta-2
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


[hidden email] 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] predicate algebra

paul womack
In reply to this post by Dakota Jack
Dakota Jack wrote:
> Sorry that this is not helpful but I was surprised to see this
> "predicate algebra".  Is this the first or second -order predicate
> calculus with or without identify?  If so, I will be hornswaggled.  I
> love that stuff.  Please let me know what this is all about.

Did you consider looking? It's this...

http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_1/org/apache/commons/collections/Predicate.html

    BugBear

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] predicate algebra

jakarta-2
In reply to this post by jakarta-2
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*[hidden email]>
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
>
>
> [hidden email] 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] predicate algebra

jakarta-2
In reply to this post by jakarta-2
On 6/7/05, jakarta*reider.net*jakarta*reider.net*7C0*qhvc*[hidden email]
<jakarta*reider.net*jakarta*reider.net*7C0*qhvc*[hidden email]>
wrote:
> // untested
> public boolean and(p2) {
>    return new Predicate(){
>       public boolean evaluate(Object input){
>          return this.evaluate(input) && p2.evaluate(input);}}}

oops that of course should have been

public Predicate and(p2) {.....

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]