Henri Yandell wrote: > On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz <phil.ste...@gmail.com> wrote: >> 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. >> Interesting idea and forces us to really think about the scopes of >> both [lang] and [collections]. Both started as really extensions of >> the JDK and both have had large parts obsoleted by advances in the >> JDK. I guess it still makes sense to consider [lang] as simple >> extensions of the JDK and [collections] as data structures. What I >> have a little trouble with is where to draw the line within >> [collections]. > > Agreed - both in terms of what we consider a simple extension of the > JDK and what we consider a data structure/algorithm. > >> I think functors is a bad example, as one could >> argue that this belongs in neither [collections] nor [lang] - oh >> wait, we did that and created [functors] (lets not divert down that >> rabbit hole ;). > > 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. > >> 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. > Not in scope - bag, buffer, transformer, > >> I am +1 on publishing the collections test jar as a separate maven >> artifact. We don't have to create a separate subproject for that, IMO. >> >> Note that lots of other commons components - [math], [net], >> [functors], [configuration], [beanutils] all come to mind >> immediately - have elements that amount to extensions of the JDK. > > [io] and [codec] are the ones that jump to mind for me, but I think > they're both still tight enough in scope that a) the committer style > is not different and b) it's not a big brain import for the users to > grok the component. Again though there's a similar style of FooUtils > classes on top of the JDK mixed with SPI type implementations. > > [beanutils] always feels like it needs replacing - something smaller > and tighter in [lang] could be a successor. > >> 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? > >> 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]. Phil > > To Paul's email - I think a wholesale merge of Collections and Lang > would be too much. It would slow down releases when we need to release > more often (that being part of my justification for splitting > Collections - the two halves would be quicker to release). I think > that similarity of scope within a component makes it more releasable > - the hardest part of Lang 3.0 is the builder subpackage, and I think > that's because it's a different style of code than much of the rest. > > 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
