commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [lang][collections] Overlap; Collections thoughts
Date Thu, 07 Jan 2010 20:56:51 GMT

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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message