On Jan 2, 2010, at 3:27 PM, Henri Yandell wrote:
On Sat, Jan 2, 2010 at 10:45 AM, Phil Steitz
<phil.ste...@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-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
