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 activity). > 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. +1 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. +1 > 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 well. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
