Briefly looking at http://svn.apache.org/repos/asf/lucene/mahout/trunk/math/src/main/java/org/apache/mahout/math/ - it looks like this is more along the lines of the Collections as new data structures/algorithms rather than Collections as JDK enhancer?
Ignoring the edge case overlaps with Math and Lang anyway. Hen On Wed, Dec 30, 2009 at 3:58 AM, Benson Margulies <bimargul...@gmail.com> wrote: > Henri, > > To make this more interesting, the new collections over in mahout-math > might be covering some of the territory you are looking for here. > > --benson > > > On Wed, Dec 30, 2009 at 5:18 AM, Henri Yandell <flame...@gmail.com> 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
