commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [lang][collections] Overlap; Collections thoughts
Date Sat, 02 Jan 2010 21:27:04 GMT
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.
* 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.

>>> 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


Mime
View raw message