[collections] New commons proper component - collections-functors

[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: [collections] New commons proper component - collections-functors

[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

[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

[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

[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

[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