On Tue, 4 Nov 2003, Herve Quiroz wrote: > On Tue, Nov 04, 2003 at 09:06:37AM -0800, Rodney Waldhoff wrote: > > On Tue, 4 Nov 2003, Herve Quiroz wrote: > > > - class Predicates: Predicates utility methods > > > > > > public static Or or(Collection predicates); > > > public static And and(Collection predicates); > > > > > > As there is no constructor for Or/And predicates with a collection as > > > parameter, these methods provide a way to get them. > > > > Sounds like a good idea, although I'm having trouble coming up with a > > reason why we just wouldn't make these methods of Or and And directly? > > > > I did that not to modify the existing ones. And moreover not to modify > the way it is (should?) be handled, that is: OR is a binary operation so > you need to compose several ORs that are "ORed" together to build an > n-ary OR. I am not sure I said it clearly enough. Maybe that's a proof > that my arguments are not relevant after all. What do you think of it ? >
Currently the AND and OR functions are not implemented as pure binary operations, but rather operations on a collection (list) of values. Specifically, each maintains a list of predicates. OR evaluates to true if at least one child evaulates to true (and hence evalutes to false when the list is empty). AND evaluates to true if all of its children evaluate to true (and hence evaluates to true when the list is empty). You can already do "new And(a,b,c)" or "new And(a).and(b).and(c)" or "new And(a,b).and(c)", etc., each of which should get you to the more or less tha same predicate. A static "factory" constructor, such as: And.and(a) ==> new And(a) or And.and(a,b) ==> new And(a,b) which would allow: And.and(a).and(b).and(c) or something like that would probably be convienient. So would: And.and(Collection) or And.and(Iterator) - Rod <http://radio.weblogs.com/0122027/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
