commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject RE: [collections] [functor] Split functors from collections
Date Fri, 25 Nov 2005 19:50:52 GMT
On Thu, 2005-11-24 at 20:09 -0500, James Carman wrote:
> I would agree that merging the functors from collections into commons
> functor would not work (Transformer vs. UnaryFunction for example).  My only
> point would be that if we're trying to create a general-purpose functor
> library (what commons functor was supposed to be), then having collections
> in the package name would be somewhat misleading.  I would be +1 to
> splitting the functors out into commons-collections-functors or something
> like that as a separate jar available with the download but not required.
> We would still leave the Transformer, Predicate, and Closure interfaces in
> the main jar, correct?  What would we do with classes like TransformerUtils?
> Would it stay in the main jar or move into the optional functor jar?

IMHO (having tried both) a flat structure is best. therefore i'd prefer
the functors to be split out into a separate component rather than an
optional jar distributed with collections. 

> I wonder why commons functor died in the first place?  No community?  It
> was/is a pretty cool library.  I used it on a couple of projects.

IIRC lack of community coupled with insufficient energy to build one.
it's hard to gather a community around a library that is basically
finished (which is why the functor code in collections has seen more

> If you'd like to compare functor sandbox and collections-functor I think 
> you'll find that they are incompatible for creating a single merged 
> sourcebase.


they are very different in design. we've never done this but i wonder
whether a portmanteau might have a chance of work (if there are
committers interested in pushing functors forward)...

> If I believed that functor sandbox was going to be resurected then I'd 
> keep collections-functor hidden in collections, but I don't so that 
> point seems moot.
> The package name remains as collections because people are using them as is.


> Nevertheless, if people feel collections should own collections-functor 
> because of the package name, then so be it. I really just want to reduce 
> the jar size.

i think that the time is right to split out functors

i can see either a portmanteau functor library or two components
(commons-collection-functors and common-general-functors) working out

i'd be interested to see how a portmanteau component would work out
(since i don't think we've tried it before). we could always split into
two components later (if it turns out to suck).

> James Carman wrote:
> > If we're going to make a general-purpose functors library (the current
> > sandbox implementation was quite nice actually), then I don't think the
> > package name should have "collections" in it, as functors aren't always
> used
> > with collections.  

the functor library in collections is popular and easy but specialised
for use in collections. the packaging should stay.

a general functor library is a different undertaking. the library in the
sandbox is a good basis for such a library. so, it's packaging also
makes sense. 
> > For example, I use Transformers during Swing development.  I have a class
> > called TransformerListCellRenderer which uses a Transformer to transform
> an
> > object into its visual representation (a string).  Most frequently I use a
> > PropertyTransformer (based on Commons BeanUtils) to display a property of
> > the object (name for example).

and i thought that i was the only one who liked using functors for
swing ;) IMHO functors are definitely under-used when developing
reusable GUIs

- robert

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

View raw message