On Jan 5, 2010, at 7:58 PM, Stephen Colebourne wrote:
[SNIP]
And splitting [collections]? Definitely a good idea. I would remove
all the Predicate/Closure/Transformer code (if you believe in FP,
use [functor]). Then split the rest by implementations of JDK
collections, and extended JDK collections - BidiMap, Bag, Trie.
+1 as I doubt any more reasonable approach exists.
-Matt
Stephen
Henri Yandell wrote:
Overlap between Lang and Collections is starting to increase a bit.
Requested items for ArrayUtils (LANG-238, LANG-470) are better
implemented imo as an ArraySet class. An easy add to Collections.
ComparableComparator made its way (privately) over for the new Range
class. Fair enough - Comparable and Comparator also overlap between
lang.* and util.*.
I have a JIRA issue threat to consider moving Collections code
over to
Lang if Collections becomes dead [LANG-532] :)
---
One thought I have for Collections is splitting it up into two parts.
The first would be items that add to collections in the JDK, the
second would be additional collections. The former could conceivably
merge with Lang, the latter could also be split up into an SPI style
approach with an API jar and an Impl jar. The latter would most
likely
depend on the former.
It would then be tempting to also merge Functors for example into the
latter, plus I think we could get back on the bandwagon of adding new
things, like the long standing Trie JIRA issue.
Biased note: Part of this is that I'm interested in the JDK enhancing
parts, but not all the implementations of weird and whacky
collections; however I think this is likely not just me and that the
separation would do wonders for the release cycle.
Thoughts?
Hen
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
