I intend to get a resolution on the functors question, as it is clearly holding things up ;-)
The approach taken to functors in general is to have lots of small functors. With your example, rather than having one predicate that receives an array of classes to check, I would probably favour one predicate that checks a class and one predicate that acts as an Or statement. Of course this means longer code in the application, but more reusable parts in commons. On a similar line, the strict vs non-strict would probably be two predicates as well. Here's hoping to a resolution of the debate on functors. Stephen ----- Original Message ----- From: "Emmanuel Bourg" <[EMAIL PROTECTED]> > This is a modified version of my previous ClassFilterIterator with a > little more meat : > - it accepts an array of classes to match several classes > - the class matching can optionnaly be "strict", that is subclasses of > the required class aren't returned. In strict mode a ClassFilterIterator > will only return objects of the same class (i.e. equals() == true) or > objects implementing the interface (but not inheriting an implementation). > > I removed the default Object.class matching when the specified class is > null (the evaluate method will throw a NPE) and made the predicate > public so that it can be reused until it is moved to a more sensible > home for predicates. > > Only the ClassPredicate is really interesting here, i agree with Rich > that there is no real need to subclass the FilterIterator class. I just > hope the lang/functor/collections debate will reach an end soon ;) > > Emmanuel > > > ---------------------------------------------------------------------------- ---- > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
