--- On Tue, 5/12/09, Stephen Colebourne <scolebou...@btopenworld.com> wrote:
> From: Stephen Colebourne <scolebou...@btopenworld.com>
> Subject: Re: [all] Core library dependencies [was COLLECTIONS 3.3 release]
> To: "Commons Developers List" <dev@commons.apache.org>
> Date: Tuesday, May 12, 2009, 6:29 AM
>
> 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".
I somewhat resent the implication that I and others might be trying to buffalo
[functor] into "proper" status, but I'm known for paranoia, so forgive me if
I've read more into that statement than was intended.
> 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.
IMO this sounds like a reason to remove functor concerns from [collections]
entirely.
>
> 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].
>
I wonder if it's worth the effort to maintain three jars for [beanutils] so
that users can use split jars of a six-class difference when the dependency is
still optional even when using the complete jar. But perhaps this is valuable
when using dependency analysis of bytecode; not being a user of such tools I
wouldn't know. From whence did the bean-collections move? [collections]?
Otherwise the analogy seems a little off.
> BTW, [collections] does publish a test-framework jar that
> [functor] could depend on as a test-only dependency.
Noted.
-Matt
>
> Stephen
>
> ---------------------------------------------------------------------
> 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
