I think this project needs a bit of documentation about it's purpose. It would seem obvious that it's about making a generic version of Commons Collections, but there are a few points that I would like to put forward:
* Should we improve on the API to reduce confusion? (I think the answer to this is yes, due to what I found in (http://sourceforge.net/tracker/index.php?func=detail&aid=1501924&group_id=139125&atid=743176)
* Should our API remove unnecessary methods that are in the apache stuff? See MapUtils.getIntValue() etc. (a form of MapUtils.getValue() would still be useful).
A few problems I have with the apache version:
* Why doesn't MapUtils.transformedMap() transform my map? In fact, on thinking, it doesn't even make sense in this new version when we want to return a generified map correctly.
* Why isn't there a CollectionUtils.toMap(Collection, keyTransformer, valueTransformer)?
I need that one all the time. In time, a CollectionTransformedMap would be good so things can be added in both manners.
* Where's Equator?
(This is a general java issue, but one that should be solved by commons collections). In java, it is assumed that objects are Equable, but not Comparable. There is a Comparator, but not an Equator.
So often I want to find an object using a certain criteria for determining equality. This opens up a whole new league of functions that would be needed.
I hardly ever use .equals() now. This would also present the need for a HashingEquator, and pluggable HashMaps etc. This is something that we should do.
In summary, I think we should maintain a 50%-80% tie to apache commons-collections, but should not be afraid of making a new, more functional, better product that has a different API from commons.
I believe that APIs should be intuitive and have sensible defaults, and apache collections does not do that for me (but it can't realistically change). We are not tied to Java 1.2 - if people are using this project, they are wanting something different and more useful.
Let's give it to them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Our specific focus with this project is to track Commons Collections functionality as closely as possible. Enhancement ideas that aren't specifically generics related should be brought over to the Apache mailing lists so we can discuss them with the Collections team at large.
Matt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think this project needs a bit of documentation about it's purpose. It would seem obvious that it's about making a generic version of Commons Collections, but there are a few points that I would like to put forward:
* Should we improve on the API to reduce confusion? (I think the answer to this is yes, due to what I found in (http://sourceforge.net/tracker/index.php?func=detail&aid=1501924&group_id=139125&atid=743176)
* Should our API remove unnecessary methods that are in the apache stuff? See MapUtils.getIntValue() etc. (a form of MapUtils.getValue() would still be useful).
A few problems I have with the apache version:
* Why doesn't MapUtils.transformedMap() transform my map? In fact, on thinking, it doesn't even make sense in this new version when we want to return a generified map correctly.
* Why isn't there a CollectionUtils.toMap(Collection, keyTransformer, valueTransformer)?
I need that one all the time. In time, a CollectionTransformedMap would be good so things can be added in both manners.
* Where's Equator?
(This is a general java issue, but one that should be solved by commons collections). In java, it is assumed that objects are Equable, but not Comparable. There is a Comparator, but not an Equator.
So often I want to find an object using a certain criteria for determining equality. This opens up a whole new league of functions that would be needed.
I hardly ever use .equals() now. This would also present the need for a HashingEquator, and pluggable HashMaps etc. This is something that we should do.
In summary, I think we should maintain a 50%-80% tie to apache commons-collections, but should not be afraid of making a new, more functional, better product that has a different API from commons.
I believe that APIs should be intuitive and have sensible defaults, and apache collections does not do that for me (but it can't realistically change). We are not tied to Java 1.2 - if people are using this project, they are wanting something different and more useful.
Let's give it to them.
Our specific focus with this project is to track Commons Collections functionality as closely as possible. Enhancement ideas that aren't specifically generics related should be brought over to the Apache mailing lists so we can discuss them with the Collections team at large.
Matt
Sorry if this is an FAQ type question, but I couldn't find an FAQ for your project.
Why are these changes not being made to the Jakarta Commons Collections project directly? I couldn't find an answer to this on Jakarta's site either.
Alright, would it then make sense to roll up a final 3.1-equivalent binary version once we're satisfied with it, then look toward 3.2 equivalency?