Re: [collections][patch] ClassFilterIterator
Tom Drake wrote: I've already submitted an OrPredicate and an InstanceOfPredicate The ClassPredicate i proposed is slightly different from the InstanceOfPredicate though, i'm not sure the strict mode can be efficiently expressed by basic predicates. Emmanuel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][patch] ClassFilterIterator
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 ClassFilterIterator.zip Description: Zip compressed data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][patch] ClassFilterIterator
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]
RE: [collections][patch] ClassFilterIterator
I've already submitted an OrPredicate and an InstanceOfPredicate -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 4:29 AM To: Jakarta Commons Developers List Subject: Re: [collections][patch] ClassFilterIterator 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][patch] ClassFilterIterator
Wouldn't it be more generic to expose your (private inner) ClassPredicate as a public Predicate, say InstanceOfPredicate? That way one could easily create ClassFilterIterator, as you have, but could also use the Predicate in the various CollectionUtils methods, etc. Also, I wonder if the ClassPredicate constructor should default to Object.class when the given Class is null. new ClassPredicate(null) or new ClassFilterIterator(null) seems like a rather confusing way to create a NotNullPredicate or a NotNullIterator. I wonder if simply throwing IllegalArgumentException or NullPointerException from the constructor would be cleaner? On Tue, 10 Dec 2002, Emmanuel Bourg wrote: Hi, here is a suggested addition to the collections component. This is a trivial FilterIterator which only returns objects of a given class. I attached the class with its associated test case. Emmanuel Bourg -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][patch] ClassFilterIterator
Actually, I've got one more comment. Not a biggie, but since I'm already here. :-) The constructor of ClassPredicate interprets a null value as equivalent to Object.class. It might be a good idea to shy away from default behaviour, and instead throw a NullPointerException. Or an IllegalArgumentException. Browse archives to see the reasons for and against throwing NPE / IEA when someone is providing an illegal argument that happens to be a null pointer. /O -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][patch] ClassFilterIterator
Hi, here is a suggested addition to the collections component. This is a trivial FilterIterator which only returns objects of a given class. I attached the class with its associated test case. Hi Emmanuel Thanks for the contribution. If I've got this right, ClassFilterIterator alters the behaviour of FilterIterator to filter its objects by their class. In this case it feels to me that using a subclass might be a bit too heavy since ClassFilterIterator isn't really altering FilterIterator's behaviour, it is just supplying a default value for its predicate. In other words, instead of Iterator classFilterIterator = new ClassFilterIterator(iterator, String.class); why not Iterator classFilterIterator = new FilterIterator(iterator, new ClassPredicate(String.class)); To me, the second example seems like the easiest and most transparent way to filter classes by their class. Perhaps you could extract the inner class and submit that separately? (Although I'm not sure where you submit it: collections, lang or functors?) Actually, I've got one more comment. Not a biggie, but since I'm already here. :-) The constructor of ClassPredicate interprets a null value as equivalent to Object.class. It might be a good idea to shy away from default behaviour, and instead throw a NullPointerException. My rationale is this: if a developer wanted to get all classes they should use Object.class or an always-true Predicate or not filter the values at all. To me, all these approaches seem a lot clearer. Rich -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
