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]
