Am 16.01.2012 17:11, schrieb Matt Benson:
Also, if you're interested in predicate-based APIs for filtering
Iterables, check out the FilteredIterable class in Commons' unreleased
[functor] component.
Matt
I had an interesting discussion about commons collections next release
with Christian Grobmeier under the topic: [ALL] suggestion for
improvement: Unify homepage layout for all commons subprojects.
The problem I have is, that there is no road map or any information on
commons collections homepage, when we can expect those new features to
be released. It would be really nice, if all projects had a road map, so
that users now, when new releases can be expected. The problem however
seems to be, as Christian pointed out, that most projects do not have
enough development activity to work after a road map.
But thanks for your hint!
Benedikt
On Mon, Jan 16, 2012 at 9:50 AM, James Ring<s...@jdns.org> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
