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]
