commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <>
Subject Re: [COLLECTIONS] 3.3 release
Date Wed, 06 May 2009 01:12:57 GMT
On Tue, May 5, 2009 at 6:36 PM, Matt Benson <> wrote:
> I feel differently--how many times do we need to duplicate code that does the same damned
thing amongst the various components?  For example, we've now added MethodUtils to [lang],
but [collections] has its own set of code supporting InvokerTransformer.  [functor] doesn't
have an analogous function because it seemed to me silly to keep rewriting and/or copying
the necessary code.  IMHO we of the Commons need to establish an approach for "mixin" components,
optional dependencies, svn externals, something, to avoid doing this again and again and again.

I'm with Matt on this one.  I really hate that Collections has its own
functors and I really hate having to copy code from one place to
another all the time.

I'd like to be able to keep my own little library of nifty functors
and use those throughout my application in different contexts.  Right
now, I have to use adapters all the time to go between one or the
other (functors vs. collections).  Yuck!  I've even gone as far as
creating little frameworky type classes that take these functor
classes (TransformerListCellRenderer and TransformerTreeCellRenderer
come to mind).

Perhaps we could split functors into an API jar and a utils or
algorithms jar?  The API would have all the main interfaces in it (the
stuff in org.apache.commons.functor).  Collections could depend on the
API and if folks want to use stuff from functor to do what they want,
then so be it.  If not, oh well.  The API itself really can't evolve
that much.  Those interfaces have been the same for a long time (other
than the generics)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message