I agree, I'm just saying you should seriously study the design of those interfaces before you embark on a project like this.
Adding a new API to a library like collections imposes a burden on maintainers that far outweighs the initial cost of the implementation. You should make sure the API is worth the cost. The guys on guava have spent serious effort designing the APIs, it's just good software engineering to duplicate as little of that effort as possible. As much as it may bother some people to hear it, I think commons should cease feature additions on collections and fix bugs only. Guava is very much superior, is favourably licensed and effort should be focused in one place. Just my two cents. I'm not an active member of Jakarta commons, just an interested third party. :-) Regards, James -- sent from my phone, excuse typos On Jan 16, 2012 3:00 AM, "Benedikt Ritter" <b...@systemoutprintln.de> wrote: > Am 15.01.2012 20:23, schrieb James Ring: > >> Google Guava has all this and more, and it doesn't require an extension to >> ArrayList, any Iterable will do. >> >> http://google-collections.**googlecode.com/svn/trunk/** >> javadoc/com/google/common/**collect/Iterables.html<http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterables.html> >> > > Hi James, > > thanks for the response! I agree with you, that google guava does the same > and that it does it better. In fact I do think, that there are things, that > guava does even better than commons collections. For example using > generics... > > However, what I do not agree with, is that this means, that there is no > need for an extension of commons collections. I mean, then ASF could also > stop developing tomcat, because there are clearly other application servers > out there, that provide all functionality that tomcat has and maybe more. > > The FAQs on how to contribute just say "if you see something that can be > improved, create a patch". And not "...that can be improved, but has not > yet been implemented in some other library". > If "not implementing functionality, that has been implemented elsewhere" > is a common policy of commons or of commons collections, then I would > recommend to put this in the FAQs on how to contribute (although I think, > that would be a very bad thing to do, as I pointed out above). > > Having all that said, I still think that linking Predicates to queries > would be a real improvement for commons collections. And I still would like > to contribute the functionality somehow. I see your point, that extending > java base classes is not the best thing to do. But as I said: I am willing > to make what ever adjustment is required (also it seems to me, that this > means re-writing the hole thing from scratch ;-) > > So, what do you think? > Regards > Benedikt > > On Jan 15, 2012 3:59 AM, "Benedikt > Ritter"<bene@systemoutprintln.**de<b...@systemoutprintln.de>> >> wrote: >> >> Hi, >>> >>> I have written a small extension for java.util.ArrayList, that allows for >>> qerrying Lists using (generic) predicates. In addition to that, I adapted >>> org.springframework.data.jpa.****domain.Specifications class as a util >>> to >>> link predicates to queries. Here is how it works: >>> >>> QueryableList<Customer> qList = new QueryableArrayList<Customer>()****; >>> qList.addAll(getCustomers()); >>> qList.getAll(new Predicate<Customer>() { >>> >>> public boolean evaluate(Customer element) { >>> if (element.getLastName().****startsWith("B")) { >>> return true; >>> } else { >>> return false; >>> } >>> } >>> }); >>> >>> This will give you a List containing all customers, that match the given >>> predicate. Using the Query class, we can link predicates via AND and OR >>> or >>> simply neglect them (the next example assumes, that we have a static >>> import >>> of the not and where method and startsWith(String) and bornAfter(int) are >>> util methods, that return predicates): >>> >>> List<Customer> queryResult = qList.getAll(not(startsWith("****B"))); >>> queryResult = qList.getAll(where(startsWith(** >>> **"B")).or(startsWith("C"))); >>> queryResult = qList.getAll(where(startsWith(** >>> **"B")).and(bornAfter(1980))); >>> >>> In addition to that, there are implementations of common collection >>> methods using predicates: >>> >>> public boolean containsMatch(Predicate<E> predicate); >>> public Iterator<E> matchIterator(Predicate<E> predicate); >>> public boolean retainAllMatches(Predicate<E> predicate); >>> public boolean removeAllMatches(Predicate<E> predicate); >>> >>> ...and common list methods: >>> >>> public int indexOfMatch(Predicate<E> predicate); >>> public int lastIndexOfMatch(Predicate<E> predicate); >>> >>> I think QueryableCollections would fit nicely into commons collections, >>> because as far as I know, commons collections only offers you the >>> opportunity to validate if all elements in a collection match a given >>> predicate. There is no possibility to easily query for objects matching >>> some criteria. >>> Having that said, I would like to contribute all source code of >>> QueryableCollections. I am willing to make what ever changes are >>> required. >>> >>> Here are some thinks that I think will need to be adjusted before >>> contribution: >>> - swtich from my generic Predicate implementation to >>> org.apache.commons.****collections.Predicate, >>> although I really would like to see generics in commons collections. It >>> saves you all the instanceof statements. >>> - As far as I can see commons collections does not extend classes from >>> java.util.* but decorates them. As I said QueryableArrayList is an >>> extension of ArrayList. If there is a general policy of not extending >>> java >>> base classes, this would have to be changed. >>> - Re-Implement jUnit tests using jUnit 3.8.1 (instead of jUnit 4.1.0) >>> - change licence agreement von LGPL to Apache License >>> >>> All source code (and example code) is available at github: >>> HEAD: >>> https://github.com/britter/****QueryableCollections<https://github.com/britter/**QueryableCollections> >>> <https://**github.com/britter/**QueryableCollections<https://github.com/britter/QueryableCollections> >>> > >>> v0.1.0: >>> https://github.com/britter/****QueryableCollections/tree/**<https://github.com/britter/**QueryableCollections/tree/**> >>> stable-0.1.0<https://github.**com/britter/**QueryableCollections/tree/** >>> stable-0.1.0<https://github.com/britter/QueryableCollections/tree/stable-0.1.0> >>> > >>> You can download a build from my blog: >>> http://www.systemoutprintln.****de/wp-content/uploads/** >>> collections-0.1.0.jar<http://**www.systemoutprintln.de/wp-** >>> content/uploads/collections-0.**1.0.jar<http://www.systemoutprintln.de/wp-content/uploads/collections-0.1.0.jar> >>> > >>> >>> I'm really exited to hear what you guys think of QueryableCollections. >>> Regards >>> Benedikt Ritter >>> >>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@commons.**apac**he.org<http://apache.org> >>> <dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org> >>> > >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > >
