Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of gudnabrsam@gmail.com
 designates 209.85.211.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:content-type:message-id
         :content-transfer-encoding:from:subject:date:to:x-mailer;
        b=chyF9feOj4ATlgbBEG7vDwYfafkMOWEeIi3NDOEK3douoHtdjnmNLiQGbZ/qKQ7MzE
         hm5Z8Qh0AO1sfYZXyp5tCS8O77mGM4xvZzKT3S0uKZ9wPdZXeqp58DQP1CNIV9Q6njih
         qgmBRHBFAxtm+Q/87iEHlrLVc55yhwk02BI2M=
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <31cc37361001021327o5ade2885p777056337e9edf19@mail.gmail.com>
References: <31cc37360912300218h450c517es8170702e9ea8fa96@mail.gmail.com>
 <4B3F7E2E.6090108@gmail.com>
 <31cc37361001021002tcffdf3csec3468e527a35ef2@mail.gmail.com>
 <4B3F9444.9090301@gmail.com>
 <31cc37361001021327o5ade2885p777056337e9edf19@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <836C940E-1590-47A6-B3D2-78A265F0456A@gmail.com>
Content-Transfer-Encoding: 7bit
From: Matt Benson <gudnabrsam@gmail.com>
Subject: Re: [lang][collections] Overlap; Collections thoughts
Date: Sun, 3 Jan 2010 11:20:07 -0600
To: "Commons Developers List" <dev@commons.apache.org>


On Jan 2, 2010, at 3:27 PM, Henri Yandell wrote:

> On Sat, Jan 2, 2010 at 10:45 AM, Phil Steitz  
> <phil.steitz@gmail.com> wrote:
>> Henri Yandell wrote:
>
>>> I was thinking more that a smaller [collections] might have room for
>>> the functor code again - not that [lang] would :) Agreed that it's
>>> better out than in though.
>>
>> That is instructive, but sort of hurts the case, though, as functors
>> are arguably closer to a language extension than they are related to
>> the [collections] domain.
>
> Agreed that it's a bad example. I'd used it as a component that had
> left collections for some reason and might be a better fit - not from
> a technical perspective. My negative to adding to Lang would be that
> unlike the Enum and NestedException pieces of code, functional-in-OO
> needs a lot of language support to feel good.
>
>>>>  Better examples of what might be peeled off into
>>>> [lang] could be the iterators or decorators.  Can you get a little
>>>> more specific on what parts of [collections] you see as in scope  
>>>> for
>>>>  merging into [lang]?
>>>
>>> https://issues.apache.org/jira/browse/LANG-532 has a bit.
>>>
>>> The various XxxUtils classes - but not the factory builder parts  
>>> that
>>> supply various aspects.
>>> A slice of the iterators and the comparators. Possibly some basic
>>> 'missing' implementations such as ArrayStack, ArraySet, FastVector
>>> etc.
>>>
>>
>> So its the bits that connect the domain to the JDK?  That would put,
>> for example, parts of o.a.c.math.stat.StatUtils,
>> o.a.c.math.util.MathUtils similarly in scope.  The question here is
>> what is special about [collections] and doesn't this just amount to
>> artificially hacking off pieces that belong with the domain?  I am
>> still not seeing the "joints" here.
>
> Lang's math.NumberUtils and math.Fraction for example. MathUtils and a
> little bit of StatUtils do look to be similar in scope.
>
> The special bits with collections are:
>
> * Lang issues are identifying overlap problems with Collections.
> ArrayUtils starts to look like Collections when you take a more
> generic approach to a problem (for example ArraySet),
> ComparableComparator was recently copied over (private class) and
> there is a ComparableUtils class request.
> * I have concerns over whether there will be a Collections 4.0.

My view on this is "eventually"--I certainly feel I've put in too  
much work to simply let [collections] go.  However, the following  
issue you identified has been a thorn in my side for quite some time  
so I am on board for streamlining, multiple artifacts, and anything  
else that will improve the situation.

> * Collections has issues that say (paraphrasing) "Nice idea, don't
> commit until Collections is lighter in weight".
> * Collections has more code at the JDK level being hidden by more
> additional features than say IO (less additional features), Codec (not
> a lot of JDK level code), Math (not a lot of JDK level code).
>
>>>> Like [collections], they all have a more specialized domain that is
>>>> their primary focus.  So the natural question is, if this makes
>>>> sense for [collections], why not everywhere else?  Answering that
>>>> question might help clarify intent here.
>>>
>>> Yup. We've already been doing it with BeanUtils - some of the code
>>> moved/copied over in 3.0.
>>>
>>> What it would possibly mean in your commons wide suggestion is a  
>>> bunch
>>> of components having a dependency on [lang], which as you say below
>>> has often been a blocker. Then again - all java.* code depends on
>>> java.lang.* :)
>>
>> Can you explain a little more what exactly has moved from BeanUtils
>> and what kinds of other things you have in mind?
>
> I thought the new reflect package was from BeanUtils. I think by way
> of the reflect sandbox component. If not code from BeanUtils, it is a
> direct overlap with some of the code at the core of BeanUtils.

That code was indeed cloned/copied from BeanUtils.  The [reflect]  
component in the sandbox didn't figure into the pedigree, though some  
of the class names there would understandably suggest otherwise (or,  
for all I know [reflect] may have also been cloned from BeanUtils  
code).  The point being that oacl.reflect provides a thin veneer over  
java.lang.reflect and thus seemed to be a proper fit.

-Matt

>
>>>> One final comment is that a logical alternative is to just split
>>>> [collections] internally into multiple pieces with separate release
>>>> cycles. Managing dependencies among the subcomponents and user
>>>> documentation might be tricky.  IIRC, that is what has prevented us
>>>> from actually ever doing this up to now.
>>>
>>> Yup. Effectively this is both a split into 'Collections JDK' and
>>> 'Collections Structures', and a merge of Collections JDK to Lang.
>>
>> A natural question to ask is is that the best way to split
>> [collections] up?  It would probably force some users to depend on -
>> and look for stuff in - [lang] when [collections] by itself would
>> now meet their needs.  Pulling the iterators, for example, out of
>> [collections] would make it harder to use by itself and I bet would
>> force [collections] itself to depend on [lang].  I am not (yet)
>> convinced that this is the best way to divide [collections].
>
> Taking things to the logical conclusion you suggest (lots of
> components pushing down into [lang]) would definitely end up with
> [lang] as a low level dependency of all. Nice in some ways, not in
> others. We could definitely use a jarjar type thing there if we got
> serious on the subject.
>
> In terms of things depending...
>
> Removing comparators from Collections would leave PriorityBuffer and
> TransformingComparator both wanting ComparableComparator. Lang also
> uses that - given that java.lang.Comparable fits in Lang and
> java.util.Comparator is taken to fit in Collections I think the
> overlap problem here is 'fine' - i.e. outside our control. This is the
> main part I began with.
>
> For Iterators - I agree. The same would be true of the various
> XxxUtils classes. How much does the rest of Collections depend on
> them. I suspect the painful part would be the most useful bits, rather
> than idiosyncrasies. There are also features that I think are less
> useful and more theoretical. ArrayListIterator on top of ArrayIterator
> - driven more by the concept of ListIterator and ResettableIterator
> (imo).
>
> 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