commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: [lang][collections] Overlap; Collections thoughts
Date Thu, 07 Jan 2010 22:47:45 GMT
But not splitting into separate releases, just separate artifacts. As
stated before, separate releases creates a compatibility matrix. These
aren't separate projects, but different areas of one.

On Thu, Jan 7, 2010 at 2:56 PM, Matt Benson <gudnabrsam@gmail.com> wrote:
>
> 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
>
>

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


Mime
View raw message