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?
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. -----Original Message----- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Thursday, November 24, 2005 7:43 PM To: Jakarta Commons Developers List Subject: Re: [collections] [functor] Split functors from collections 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. 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. Stephen 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. > > 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). > > -----Original Message----- > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 24, 2005 6:58 PM > To: Jakarta Commons Developers List > Subject: Re: [collections] [functor] Split functors from collections > > Does it actually need a deprecation release? The new component will have > the same classes in the same packages. The only difference is that users > will need to pickup another jar. > > In fact, since this is the case, deprecation will actually cause > confusion to users. Depending on which is first in their classpath, they > user will get either the deprecated (from collections) or the > non-deprecated (from functors) version of the same class! > > As to the functor sandbox component, I believe that is best developed > separately from commons. The interfaces just clash in name and design > with collections, that I think we would always have had problems > releasing it (even if it had got a community). > > Stephen > > > Dion Gillard wrote: > >>+1 to the split. >> >>Proposal A would seem to make the most sense. >> >>I'd like to see a 'deprecation release' of collections with the >>functor code marked as deprecated so that users know this is being >>moved. >> >>This would give be a big heads up about the new component and that >>their build process should change. >> >>On 11/25/05, Stephen Colebourne <[EMAIL PROTECTED]> wrote: >> >> >>>Commons collections is a large jar file. Some users have issue with >>>that. Those users tend to complain most about the functor part, which is >>>an area of more religious feeling than the rest of collections. >>> >>>I want to float the idea therefore of splitting the functors away from >>>collections. This was done once before with primitives. >>> >>>Proposal A is to create a new commons proper component [functors] which >>>contains the functors subpackage and the four functor *Utils classes and >>>releasing commons-functors.jar. The package name would not change (this >>>is as per [primitives]). This proposal works because [functors] and >>>[collections] could easily be on different release schedules. >>> >>>Proposal B is to just release [collections] as two jars, >>>commons-collections (no functors) and commons-collections-functor. >>> >>>Thoughts? >>> >>>Stephen >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >>-- >>http://www.multitask.com.au/people/dion/ >>"You are going to let the fear of poverty govern your life and your >>reward will be that you will eat, but you will not live." - George >>Bernard Shaw >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
