commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: [all] Core library dependencies [was COLLECTIONS 3.3 release]
Date Tue, 12 May 2009 13:40:03 GMT



--- On Tue, 5/12/09, Stephen Colebourne <scolebourne@btopenworld.com> wrote:

> From: Stephen Colebourne <scolebourne@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 <thinman42@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


      

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message