From: John Bollinger <thinma...@yahoo.com> > Which is exactly why Collections should not copy Functor. Either Functor > should be absorbed back into Collections, or Collections should have > Functor as a dependency, for otherwise users must maintain separate > functors for use with Collections and for other purposes. Users of both can > rely on the Collections functors for everything, but that de facto rolls > Functor into Collections for them. It also obligates them to adhere to that > approach, which has great potential for integration pain. > > A key issue here is that parts of the Collections public API reference > classes / interfaces of Functor. Collections therefore must either own > Functor > or depend on it. There is no reasonable way to split the two projects without > making one depend on the other. This is different from the case in some > Commons projects where classes are copied from another Commons > component for private, internal-only use. Note also that the same argument > applies to moving the functor-based collections to Functor: then Functor would > need to have Collections as a dependency.
The 'functors' in [collections] and [functor] are very different: http://commons.apache.org/collections/api-release/org/apache/commons/collections/package-summary.html http://commons.apache.org/sandbox/functor/apidocs/org/apache/commons/functor/package-summary.html There is no need to share these interfaces, add dependencies or anything similar. (Equally, were they the same John's argument would be sound.) What [functor] needs is the confidence to stand up and say "hey, come and use me, here's what I offer". There is good stuff in [functor], but critically it is a semi-religious approach to coding. By this, I mean that developers have to "buy-in" to the idea that writing and using lots of small inner classes in a compositional fashion is what they want. And exactly in the same way as many developers don't like functional programming, many won't like the [functor] approach. That doesn't make it bad or wrong, it just means that it needs to stand up and own its own space. Users should want to use [functor] for what it offers. They need to make a positive choice. Now look at the other angle - what do users of [collections] want? Its additional implementations of JCF collections, and new related collection interfaces. In many ways, its a historic oddity that [collections] has any functor-like stuff at all. Many (most) users of collections are not interested in the functor-type stuff I'd suggest. My strong recommendation is to add key collection classes to [functor] (directly implementing the JDK List/Set/Map interfaces). They differ from those in [collections] because the API of Predicate/Function etc is so different. Then promote [functor] to commons-proper with no dependencies. Then, [collections] can, over time, consider if it wishes to deprecate and remove its own functor based collections in favour of those in [functor], without ever needing a dependency beyond the JDK. This is exactly how the bean sytle collections were moved out to [bean-collections]. BTW, [collections] does publish a test-framework jar that [functor] could depend on as a test-only dependency. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
