You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2005/11/29 00:12:12 UTC
[VOTE] New commons proper component - collections-functors
The [collections] component would like to split out a new commons proper
component, [collection-functors]. This component will be created
directly in commons proper, not the sandbox as it contains code
previously released. The primary motivations are to reduce to amount of
code held within [collections] itself (and thus the jar size), to allow
the functor part to grow and to allow independent release cycles.
The new component will use the same package name as at present -
o.a.commons.collections.functors, and will produce a jar with the name
commons-collection-functors.jar. This new component will be at the top
level as far as maven and other tools are concerned.
Please note that this is unrelated to the [functor] component in the
sandbox.
-----------------------
[ ] +1 I support creating [collection-functors]
[ ] +0 It's OK
[ ] +1 If you must
[ ] -1 I don't support this because....
-----------------------
Voting open for 72 hours.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] New commons proper component - collections-functors
Posted by Rahul Akolkar <ra...@gmail.com>.
On 11/28/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> The [collections] component would like to split out a new commons proper
> component, [collection-functors]. This component will be created
> directly in commons proper, not the sandbox as it contains code
> previously released. The primary motivations are to reduce to amount of
> code held within [collections] itself (and thus the jar size), to allow
> the functor part to grow and to allow independent release cycles.
>
> The new component will use the same package name as at present -
> o.a.commons.collections.functors, and will produce a jar with the name
> commons-collection-functors.jar. This new component will be at the top
> level as far as maven and other tools are concerned.
>
> Please note that this is unrelated to the [functor] component in the
> sandbox.
>
> -----------------------
> [ ] +1 I support creating [collection-functors]
> [ ] +0 It's OK
> [ ] +1 If you must
> [ ] -1 I don't support this because....
> -----------------------
<snip/>
<ballot-query>
Was it your intention to have two +1 options? The second appears to imply -0?
</ballot-query>
-Rahul
>
> Voting open for 72 hours.
>
> Stephen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] New commons proper component - collections-functors
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2005-11-28 at 23:12 +0000, Stephen Colebourne wrote:
<snip>
> -----------------------
> [X] +1 I support creating [collection-functors]
> [ ] +0 It's OK
> [ ] +1 If you must
> [ ] -1 I don't support this because....
> -----------------------
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [VOTE] New commons proper component - collections-functors
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Wed, 2005-11-30 at 16:17 -0500, Michael Heuer wrote:
> robert burrell donkin wrote:
>
> > On Tue, 2005-11-29 at 15:09 +0000, Tim Roberts wrote:
> > > +1 I support creating a functors library (but not necessarily called
> > > collections-functors).
> > >
> > > Rational:
> > > I think functors are a powerful approach to software design, under
> > > represented (in java) and non-standardised. I would like to see functors
> > > (sandbox) integrated and have a common interface set (and would like to help
> > > with such an undertaking). In addition to reducing the size of collections
> > > developers would, IMO, like to be able to use functors separately from
> > > collections.
> >
> > i'm beginning to suspect that there are number of secret functor users
> > out there...
> >
> > a lack of community prevented the functor component progressing from the
> > sandbox. perhaps times have changed and there may be now enough
> > momentum. would need a committer with enough time as well as enough
> > interested developers...
> >
> > opinions?
>
> I think maybe you stated that backward -- the fact that the functor
> component was in the common sandbox may have prevented [functor] from
> gathering a community.
not backward, just a bit circular :)
> How can a sandbox component gather users without a
> release?
that's why it's traditionally been tough for a component to progress
from the sandbox to proper. one reason for requiring a community is that
the core commons committers only have so many cycles so there's a
resistance to taking on components which may be self-sustaining. another
is that apache is interested in community development.
so, it's really developers (rather than users) that are most important
for sandbox components.
> There is a lot of functor-related activity out there:
>
> Functor Objects (Wiki)
> > http://c2.com/cgi/wiki?FunctorObject
>
> Blocks In Java (Wiki)
> > http://c2.com/cgi/wiki?BlocksInJava
>
> jga - Generic Algorithms for Java
> > http://jga.sourceforge.net
>
> Colt Project
> > http://dsd.lbl.gov/~hoschek/colt
>
> More functor interfaces
> > http://www.dishevelled.org/functor
yep :)
the question is whether there's enough enthusiasm out there now to
sustain a commons generic functor component...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [VOTE] New commons proper component - collections-functors
Posted by Michael Heuer <he...@acm.org>.
robert burrell donkin wrote:
> On Tue, 2005-11-29 at 15:09 +0000, Tim Roberts wrote:
> > +1 I support creating a functors library (but not necessarily called
> > collections-functors).
> >
> > Rational:
> > I think functors are a powerful approach to software design, under
> > represented (in java) and non-standardised. I would like to see functors
> > (sandbox) integrated and have a common interface set (and would like to help
> > with such an undertaking). In addition to reducing the size of collections
> > developers would, IMO, like to be able to use functors separately from
> > collections.
>
> i'm beginning to suspect that there are number of secret functor users
> out there...
>
> a lack of community prevented the functor component progressing from the
> sandbox. perhaps times have changed and there may be now enough
> momentum. would need a committer with enough time as well as enough
> interested developers...
>
> opinions?
I think maybe you stated that backward -- the fact that the functor
component was in the common sandbox may have prevented [functor] from
gathering a community. How can a sandbox component gather users without a
release?
There is a lot of functor-related activity out there:
Functor Objects (Wiki)
> http://c2.com/cgi/wiki?FunctorObject
Blocks In Java (Wiki)
> http://c2.com/cgi/wiki?BlocksInJava
jga - Generic Algorithms for Java
> http://jga.sourceforge.net
Colt Project
> http://dsd.lbl.gov/~hoschek/colt
More functor interfaces
> http://www.dishevelled.org/functor
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [VOTE] New commons proper component - collections-functors
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-11-29 at 15:09 +0000, Tim Roberts wrote:
> +1 I support creating a functors library (but not necessarily called
> collections-functors).
>
> Rational:
> I think functors are a powerful approach to software design, under
> represented (in java) and non-standardised. I would like to see functors
> (sandbox) integrated and have a common interface set (and would like to help
> with such an undertaking). In addition to reducing the size of collections
> developers would, IMO, like to be able to use functors separately from
> collections.
i'm beginning to suspect that there are number of secret functor users
out there...
a lack of community prevented the functor component progressing from the
sandbox. perhaps times have changed and there may be now enough
momentum. would need a committer with enough time as well as enough
interested developers...
opinions?
> PS I'm new to this open-source community stuff so apologies for any
> mistakes/inappropriate actions (such as voting on this change).
you're very welcome to cast a vote but only some votes are binding.
(binding votes are those that count towards the final tally.) you'll
often see folks express this sometimes as '+1 (non-binding)'. (there's a
wiki page on nettiquette
http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette.)
here at apache, we like to encourage as many people as possible to
contribute to development and an important way of doing that is to
debate decisions. votes are just one part of that process, a way to
focus the debate.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [VOTE] New commons proper component - collections-functors
Posted by Tim Roberts <tr...@computing.dundee.ac.uk>.
+1 I support creating a functors library (but not necessarily called
collections-functors).
Rational:
I think functors are a powerful approach to software design, under
represented (in java) and non-standardised. I would like to see functors
(sandbox) integrated and have a common interface set (and would like to help
with such an undertaking). In addition to reducing the size of collections
developers would, IMO, like to be able to use functors separately from
collections.
Tim.
PS I'm new to this open-source community stuff so apologies for any
mistakes/inappropriate actions (such as voting on this change).
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: 29 November 2005 01:13
To: Jakarta Commons Developers List
Subject: Re: [VOTE] New commons proper component - collections-functors
Reissued ballot paper as I can't use Ctrl+C...
-----------------------
[ ] +1 I support creating [collection-functors]
[ ] +0 It's OK
[ ] -0 If you must
[ ] -1 I don't support this because....
-----------------------
Stephen
Stephen Colebourne wrote:
> The [collections] component would like to split out a new commons proper
> component, [collection-functors]. This component will be created
> directly in commons proper, not the sandbox as it contains code
> previously released. The primary motivations are to reduce to amount of
> code held within [collections] itself (and thus the jar size), to allow
> the functor part to grow and to allow independent release cycles.
>
> The new component will use the same package name as at present -
> o.a.commons.collections.functors, and will produce a jar with the name
> commons-collection-functors.jar. This new component will be at the top
> level as far as maven and other tools are concerned.
>
> Please note that this is unrelated to the [functor] component in the
> sandbox.
>
> -----------------------
> [ ] +1 I support creating [collection-functors]
> [ ] +0 It's OK
> [ ] +1 If you must
> [ ] -1 I don't support this because....
> -----------------------
>
> Voting open for 72 hours.
>
> Stephen
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] New commons proper component - collections-functors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Reissued ballot paper as I can't use Ctrl+C...
-----------------------
[ ] +1 I support creating [collection-functors]
[ ] +0 It's OK
[ ] -0 If you must
[ ] -1 I don't support this because....
-----------------------
Stephen
Stephen Colebourne wrote:
> The [collections] component would like to split out a new commons proper
> component, [collection-functors]. This component will be created
> directly in commons proper, not the sandbox as it contains code
> previously released. The primary motivations are to reduce to amount of
> code held within [collections] itself (and thus the jar size), to allow
> the functor part to grow and to allow independent release cycles.
>
> The new component will use the same package name as at present -
> o.a.commons.collections.functors, and will produce a jar with the name
> commons-collection-functors.jar. This new component will be at the top
> level as far as maven and other tools are concerned.
>
> Please note that this is unrelated to the [functor] component in the
> sandbox.
>
> -----------------------
> [ ] +1 I support creating [collection-functors]
> [ ] +0 It's OK
> [ ] +1 If you must
> [ ] -1 I don't support this because....
> -----------------------
>
> Voting open for 72 hours.
>
> Stephen
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[RESULT] [VOTE] New commons proper component - collections-functors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
+1
Stephen Colebourne
Robert Burrel Donkin
James Carmen
Phil Steitz
The vote passed, but not without debate.
I'll take this debate back to [collections], probably after Javapolis.
Stephen
Stephen Colebourne wrote:
> The [collections] component would like to split out a new commons proper
> component, [collection-functors]. This component will be created
> directly in commons proper, not the sandbox as it contains code
> previously released. The primary motivations are to reduce to amount of
> code held within [collections] itself (and thus the jar size), to allow
> the functor part to grow and to allow independent release cycles.
>
> The new component will use the same package name as at present -
> o.a.commons.collections.functors, and will produce a jar with the name
> commons-collection-functors.jar. This new component will be at the top
> level as far as maven and other tools are concerned.
>
> Please note that this is unrelated to the [functor] component in the
> sandbox.
>
> -----------------------
> [ ] +1 I support creating [collection-functors]
> [ ] +0 It's OK
> [ ] +1 If you must
> [ ] -1 I don't support this because....
> -----------------------
>
> Voting open for 72 hours.
>
> Stephen
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [VOTE] New commons proper component - collections-functors
Posted by James Carman <ja...@carmanconsulting.com>.
James Carman: +1
Did you mean "-0 If you must"?
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: Monday, November 28, 2005 6:12 PM
To: Jakarta Commons Developers List
Subject: [VOTE] New commons proper component - collections-functors
The [collections] component would like to split out a new commons proper
component, [collection-functors]. This component will be created
directly in commons proper, not the sandbox as it contains code
previously released. The primary motivations are to reduce to amount of
code held within [collections] itself (and thus the jar size), to allow
the functor part to grow and to allow independent release cycles.
The new component will use the same package name as at present -
o.a.commons.collections.functors, and will produce a jar with the name
commons-collection-functors.jar. This new component will be at the top
level as far as maven and other tools are concerned.
Please note that this is unrelated to the [functor] component in the
sandbox.
-----------------------
[ ] +1 I support creating [collection-functors]
[ ] +0 It's OK
[ ] +1 If you must
[ ] -1 I don't support this because....
-----------------------
Voting open for 72 hours.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] New commons proper component - collections-functors
Posted by Thomas Dudziak <to...@gmail.com>.
On 11/29/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> The new component is [collection-functors], so there
> should be no confusion.
Ok, you're right, that would be clear.
> I do expect different release cycles going forward.
> There is only a small tie between the two bits of code
> (4 interfaces).
>
> What we are arguing is that delivering two jars within
> one project actually *hides* what is really going on,
> which is two separately released codebases. This
> clarifies the end result by making truly independent
> projects.
Ok, but then I agree with Phil: the distinction/overlap/relation
should be made clear IMHO. I haven't used functor yet, but perhaps
collections-functors makes sense as part of functor ?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] New commons proper component - collections-functors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
--- Thomas Dudziak <to...@gmail.com> wrote:
> On 11/29/05, Stephen Colebourne
> <sc...@btopenworld.com> wrote:
> > TransformerUtils -> [collection-functors]
> > PredicateUtils -> [collection-functors]
> > ClosureUtils -> [collection-functors]
> > FactoryUtils -> [collection-functors]
> >
> > Transformer -> [collections]
> > Predicate -> [collections]
> > Closure -> [collections]
> > Factory -> [collections]
>
> If the functors (and you should choose a new name,
> its much too close
> to commons-functor)
The new component is [collection-functors], so there
should be no confusion.
> If the functors are so closely tied to
> commons-collections, why
> don't you distribute the commons-collections lib in
> two variants ? One
> could contain only the core functionality, say
> commons-collections-core.jar, and the other the
> complete collections
> lib, say commons-collections-full.jar.
> Do you expect the new component to have a higher
> release cycle than
> commons-collections itself ? If not, than IMHO that
> would not justify
> a new commons component.
I do expect different release cycles going forward.
There is only a small tie between the two bits of code
(4 interfaces).
What we are arguing is that delivering two jars within
one project actually *hides* what is really going on,
which is two separately released codebases. This
clarifies the end result by making truly independent
projects.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] New commons proper component - collections-functors
Posted by Thomas Dudziak <to...@gmail.com>.
On 11/29/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> James Carman wrote:
> > So, TransformerUtils would have to move into the new component, right?
> > Would the Transformer, Closure, and Predicate interfaces stay in the core
> > package or go into the new component?
>
> TransformerUtils -> [collection-functors]
> PredicateUtils -> [collection-functors]
> ClosureUtils -> [collection-functors]
> FactoryUtils -> [collection-functors]
>
> Transformer -> [collections]
> Predicate -> [collections]
> Closure -> [collections]
> Factory -> [collections]
If the functors (and you should choose a new name, its much too close
to commons-functor) are so closely tied to commons-collections, why
don't you distribute the commons-collections lib in two variants ? One
could contain only the core functionality, say
commons-collections-core.jar, and the other the complete collections
lib, say commons-collections-full.jar.
Do you expect the new component to have a higher release cycle than
commons-collections itself ? If not, than IMHO that would not justify
a new commons component.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] New commons proper component - collections-functors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
robert burrell donkin wrote:
>>>[sandbox-functor] has *nothing* in common with [collection-functor]. Nor
>>>is it going to. The source and approaches are just different.
>
>
> is see that as a good thing, not bad :)
>
> thinking back, one of the sources of arguments about functors has been
> that the functors in collections are specialist (and not a general
> library) but the functors in the sandbox as generic (and so not so
> convenient when used in the specialist domain of collections). so maybe
> there would be space for both in a common-functor component...
I have to say that I believe that trying to force two disparate
codebases together seems a very bad idea. The commons charter suggests
that there may be two ways to implement the same thing.
BTW, ideally we'd come up with a new name for one of these two that
didn't involve 'functor'.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] New commons proper component -
collections-functors
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-11-29 at 19:38 -0700, Phil Steitz wrote:
> Thanks, Stephen. While I still think 1, 5 are problematic, your
> responses to the other points are enough to move me to +1
>
> Phil
> On 11/29/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > Phil Steitz wrote:
> > > -0 for following reasons:
> > >
> > > 1. I am having a hard time understanding what the value
> > > commons-functor by itself is going to be. How do we expect it to
> > > "grow" - independently of collections - other than by replicating
> > > functionality in [functor]?
> > Functor in the sandbox may well be a better designed, purer functor
> > library, but it has not seen any activity in a long time.
> >
> > Collections functor package has had a number of proposed patches for new
> > functors which I have had to reject as they bloat the collections jar
> > file. As an independent jar file, only taken by those who want the
> > collections functors, these new functors could be happily accepted.
it also turns out that james carman and i both use functors extensively
for swing GUIs. (i thought i was the only one with that particular
madness ;) so, there's probably a sufficient micro-community for
functor.
the sandbox functor component is good but independent and incompatible
design. creating common-functor based on the collections code would not
exclude the possible of including the sandbox code as part of
commons-functor as a generic implementation rather than the specialist
code from collections.
> > > 5. (could be viewed as expansion of 1) I don't like the idea of
> > > promoting a bare-bones functor library when we have a much more fully
> > > functional one in the sandbox. Though my French is a little rusty, I
> > > like Robert's idea of a "portmanteaux" and would like to think
> > > carefully about that option before creating a functor component
> > > completely independent of [functor].
>
> > [sandbox-functor] has *nothing* in common with [collection-functor]. Nor
> > is it going to. The source and approaches are just different.
is see that as a good thing, not bad :)
thinking back, one of the sources of arguments about functors has been
that the functors in collections are specialist (and not a general
library) but the functors in the sandbox as generic (and so not so
convenient when used in the specialist domain of collections). so maybe
there would be space for both in a common-functor component...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] New commons proper component -
collections-functors
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-11-29 at 23:31 -0500, Henri Yandell wrote:
> +1 to the new library.
>
> I'm wondering if we reach a point where Collections wants Primitives
> and Collections-Functor as subcomponents. Tricky to handle with our
> current setup, but maybe an idea for the future.
i once thought that subcomponents were a reasonable idea. (logging
(unreleased) and beanutils have subcomponents.) experience has taught me
that really the separate component approach (used by primitives) is
better in the long run: sub-components tend to get hidden and increase
the complexity of the build and confused users. i really think that the
original vision: lots of small equal bricks has stood the test of time.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] New commons proper component - collections-functors
Posted by Henri Yandell <fl...@gmail.com>.
+1 to the new library.
I'm wondering if we reach a point where Collections wants Primitives
and Collections-Functor as subcomponents. Tricky to handle with our
current setup, but maybe an idea for the future.
Hen
On 11/29/05, Phil Steitz <ph...@gmail.com> wrote:
> Thanks, Stephen. While I still think 1, 5 are problematic, your
> responses to the other points are enough to move me to +1
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] New commons proper component - collections-functors
Posted by Phil Steitz <ph...@gmail.com>.
Thanks, Stephen. While I still think 1, 5 are problematic, your
responses to the other points are enough to move me to +1
Phil
On 11/29/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Phil Steitz wrote:
> > -0 for following reasons:
> >
> > 1. I am having a hard time understanding what the value
> > commons-functor by itself is going to be. How do we expect it to
> > "grow" - independently of collections - other than by replicating
> > functionality in [functor]?
> Functor in the sandbox may well be a better designed, purer functor
> library, but it has not seen any activity in a long time.
>
> Collections functor package has had a number of proposed patches for new
> functors which I have had to reject as they bloat the collections jar
> file. As an independent jar file, only taken by those who want the
> collections functors, these new functors could be happily accepted.
>
> > 2. The small reduction in jar size for [collections] that may appeal
> > to a small number of users might be cancelled by the annoyance of a
> > possibly larger number of users who will have to change dependencies,
> > classpaths, etc to add the new jar if they need it.
> Currently, collections is 550K and almost certainly the largest
> sourcebase in commons. It must reduce in size. Period. Functors are the
> most consistently referred to item that could be removed.
>
> Either a new component is created, or a new jar within collections is
> created. I believe that the latter hides what is going on.
>
> > 3. Given the relatively tight coupling above, I don't see the
> > rationale for creating a separate component. If we want to ship
> > [collections] in 2 or more jars (we already do that for the test
> > framework) that is fine (modulo the inconvenience factor), but I don't
> > (yet) see the need for creating another component.
> Releasing multiple jars from one project is actually quite nasty. (for a
> start you can throw maven out). More significantly, it just hides the
> functionality. BTW, this isn't new - [primitives] is exactly the same as
> what we are discussing here.
>
> > 4. This adds intra-commons dependencies, which I have come to agree is
> > not a good idea, especially for widely used base components such as
> > [collections]. Allowing [collections] and [collections-functor] to
> > release independently is asking for the problems associated with these
> > dependencies.
> The dependency is from [collection-functor] two four interfaces in
> [collections]. These interfaces have not changed since they were
> originally released, and will not change. It would even be possible to
> include the interfaces in the [collection-functor] jar and have no
> dependency.
>
> > 5. (could be viewed as expansion of 1) I don't like the idea of
> > promoting a bare-bones functor library when we have a much more fully
> > functional one in the sandbox. Though my French is a little rusty, I
> > like Robert's idea of a "portmanteaux" and would like to think
> > carefully about that option before creating a functor component
> > completely independent of [functor].
> [sandbox-functor] has *nothing* in common with [collection-functor]. Nor
> is it going to. The source and approaches are just different.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[collections] New commons proper component - collections-functors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Phil Steitz wrote:
> -0 for following reasons:
>
> 1. I am having a hard time understanding what the value
> commons-functor by itself is going to be. How do we expect it to
> "grow" - independently of collections - other than by replicating
> functionality in [functor]?
Functor in the sandbox may well be a better designed, purer functor
library, but it has not seen any activity in a long time.
Collections functor package has had a number of proposed patches for new
functors which I have had to reject as they bloat the collections jar
file. As an independent jar file, only taken by those who want the
collections functors, these new functors could be happily accepted.
> 2. The small reduction in jar size for [collections] that may appeal
> to a small number of users might be cancelled by the annoyance of a
> possibly larger number of users who will have to change dependencies,
> classpaths, etc to add the new jar if they need it.
Currently, collections is 550K and almost certainly the largest
sourcebase in commons. It must reduce in size. Period. Functors are the
most consistently referred to item that could be removed.
Either a new component is created, or a new jar within collections is
created. I believe that the latter hides what is going on.
> 3. Given the relatively tight coupling above, I don't see the
> rationale for creating a separate component. If we want to ship
> [collections] in 2 or more jars (we already do that for the test
> framework) that is fine (modulo the inconvenience factor), but I don't
> (yet) see the need for creating another component.
Releasing multiple jars from one project is actually quite nasty. (for a
start you can throw maven out). More significantly, it just hides the
functionality. BTW, this isn't new - [primitives] is exactly the same as
what we are discussing here.
> 4. This adds intra-commons dependencies, which I have come to agree is
> not a good idea, especially for widely used base components such as
> [collections]. Allowing [collections] and [collections-functor] to
> release independently is asking for the problems associated with these
> dependencies.
The dependency is from [collection-functor] two four interfaces in
[collections]. These interfaces have not changed since they were
originally released, and will not change. It would even be possible to
include the interfaces in the [collection-functor] jar and have no
dependency.
> 5. (could be viewed as expansion of 1) I don't like the idea of
> promoting a bare-bones functor library when we have a much more fully
> functional one in the sandbox. Though my French is a little rusty, I
> like Robert's idea of a "portmanteaux" and would like to think
> carefully about that option before creating a functor component
> completely independent of [functor].
[sandbox-functor] has *nothing* in common with [collection-functor]. Nor
is it going to. The source and approaches are just different.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] New commons proper component - collections-functors
Posted by Phil Steitz <ph...@gmail.com>.
On 11/28/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> James Carman wrote:
> > So, TransformerUtils would have to move into the new component, right?
> > Would the Transformer, Closure, and Predicate interfaces stay in the core
> > package or go into the new component?
>
> TransformerUtils -> [collection-functors]
> PredicateUtils -> [collection-functors]
> ClosureUtils -> [collection-functors]
> FactoryUtils -> [collection-functors]
>
> Transformer -> [collections]
> Predicate -> [collections]
> Closure -> [collections]
> Factory -> [collections]
>
> Stephen
-0 for following reasons:
1. I am having a hard time understanding what the value
commons-functor by itself is going to be. How do we expect it to
"grow" - independently of collections - other than by replicating
functionality in [functor]?
2. The small reduction in jar size for [collections] that may appeal
to a small number of users might be cancelled by the annoyance of a
possibly larger number of users who will have to change dependencies,
classpaths, etc to add the new jar if they need it.
3. Given the relatively tight coupling above, I don't see the
rationale for creating a separate component. If we want to ship
[collections] in 2 or more jars (we already do that for the test
framework) that is fine (modulo the inconvenience factor), but I don't
(yet) see the need for creating another component.
4. This adds intra-commons dependencies, which I have come to agree is
not a good idea, especially for widely used base components such as
[collections]. Allowing [collections] and [collections-functor] to
release independently is asking for the problems associated with these
dependencies.
5. (could be viewed as expansion of 1) I don't like the idea of
promoting a bare-bones functor library when we have a much more fully
functional one in the sandbox. Though my French is a little rusty, I
like Robert's idea of a "portmanteaux" and would like to think
carefully about that option before creating a functor component
completely independent of [functor].
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] New commons proper component - collections-functors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
James Carman wrote:
> So, TransformerUtils would have to move into the new component, right?
> Would the Transformer, Closure, and Predicate interfaces stay in the core
> package or go into the new component?
TransformerUtils -> [collection-functors]
PredicateUtils -> [collection-functors]
ClosureUtils -> [collection-functors]
FactoryUtils -> [collection-functors]
Transformer -> [collections]
Predicate -> [collections]
Closure -> [collections]
Factory -> [collections]
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [VOTE] New commons proper component - collections-functors
Posted by James Carman <ja...@carmanconsulting.com>.
So, TransformerUtils would have to move into the new component, right?
Would the Transformer, Closure, and Predicate interfaces stay in the core
package or go into the new component?
-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
Sent: Monday, November 28, 2005 6:12 PM
To: Jakarta Commons Developers List
Subject: [VOTE] New commons proper component - collections-functors
The [collections] component would like to split out a new commons proper
component, [collection-functors]. This component will be created
directly in commons proper, not the sandbox as it contains code
previously released. The primary motivations are to reduce to amount of
code held within [collections] itself (and thus the jar size), to allow
the functor part to grow and to allow independent release cycles.
The new component will use the same package name as at present -
o.a.commons.collections.functors, and will produce a jar with the name
commons-collection-functors.jar. This new component will be at the top
level as far as maven and other tools are concerned.
Please note that this is unrelated to the [functor] component in the
sandbox.
-----------------------
[ ] +1 I support creating [collection-functors]
[ ] +0 It's OK
[ ] +1 If you must
[ ] -1 I don't support this because....
-----------------------
Voting open for 72 hours.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org