[collections][lang] Functors, pre-vote

[Stephen Colebourne <sc...@btopenworld.com>]

On a number of occasions we have received requests for implementations of
the Functors (Predicate, Transformer, Closure and Factory). These
implementations now exist in [lang], however they implement the [lang]
version of the interfaces, not the [collections] version. This problem must
be solved. I am prepared to do the work, but this requires a plan and a
vote. That way we can hopefully avoid the kind of continual reopening of
this issue that has happened. This mail aims to get opinions before moving
to a vote.


Solution #1
Move functor code from [lang] to [collections].
+ [collections] does not depend on [lang]
- You can want to use a Functor without wanting [collections], for example
[io]
- Causes problems if [lang] wants to use a functor

Solution #2
[collections] depends on [lang], with the collections interfaces deprecated
in favour of the lang ones.
+ [collections] focuses on collections only, not functors
+ functors in [lang] makes them available to other projects like [io] easily
- [collections] depends on [lang]
- functors provoke debate as to whether they should be in [lang]

Solution #3
[functor] project, that contains the functor interfaces, implementations and
CollectionUtils implementations, with the collections interfaces and
CollectionUtils code deprecated in favour of the functor ones.
+ all functor code is together, all collections code is together. Tight
scope
+ [collections] does not depend on [lang]
+ [functor does not depend on [collections], which is better for [io] etc.
- [functor] depends on [lang]
- Functor users, like [io], need to depend on [functor] and [lang]
- Causes problems if [lang] wants to use a functor

Solution #4  (Tried and failed)
[pattern] project that contains the functor interfaces and implementations
This failed because:
a) [collections] was asked to depend on [pattern] and [lang]
b) [pattern] was too braodly scoped
c) [pattern] was badly named

Solution #5  (Included, for completeness)
Duplicate the functor implementations in [lang] and [collections]
- This sucks


#1 is the simplest choice, but messes up other projects who want to use
functors without collections

#2 is a simple choice, but requires [collections] to depend on [lang] and
people to be comfortable the functors should be in [lang].

#3 requires more initial effort, but does result in more tightly defined
components.

I am prepared to implement #1, #2 or #3 to get this sorted finally. Or are
there any other options I haven't thought of?

Stephen




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[Stephen Colebourne <sc...@btopenworld.com>]

>>  Does it matter if [functor] and [lang] have circular dependencies? Not
>>  that they will.

Ola:
> Yes, that does matter.
> The thing is: should [functor] contain the util classes with default
implementations etc. If so, I am compelled to say that it should go into
[lang].

There is no real requirement for [functor] to depend on [lang].

If it were just my choice, then I would favour larger packages, and leave
functors in [lang]. However, there seems to be more of a consensus for
smaller packages.

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[Rodney Waldhoff <rw...@apache.org>]

On Thu, 12 Dec 2002, Ola Berg wrote:

> The thing is: should [functor] contain the util classes with default
> implementations etc. If so, I am compelled to say that it should go into
> [lang].

In my opinion, yes [functor] should contain the most basic and common
Functor implementations.  You're only gonna want common Functor
implementations if you're using Functor (common reuse) and if something
changes in the basic Functor interfaces, then these common implmentations
will likely also need to change (common change).

This does not necessarily imply that both the Functor interfaces and the
basic Functor implementations would need to go into the same JAR or cvs
directory. It is possible to separate the interface classes from the
implementations, even to have distinct dependencies for the two.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[Ola Berg <ol...@ports.se>]

> Does it matter if [functor] and [lang] have circular dependencies? Not
> that they will.

Yes, that does matter.

The thing is: should [functor] contain the util classes with default implementations etc. If so, I am compelled to say that it should go into [lang].

/O




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[Stephen Colebourne <sc...@btopenworld.com>]

> > Does it matter if [functor] and [lang] have circular dependencies? Not
> > that they will.
>
> it appears that [functor] will need to depend on [lang] for exception
> nesting.
>
> hopefully, lang will not need to depend on functor. if it does, then maybe
> it shows that the factoring has gone a bit wrong and we need to think
> about it again.

The proposal will be to break the dependency on [lang]. Exceptions will be
independent of NestedException, and any other [lang] code (believed to only
be SerialisationUtils.clone()) will be copied.

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[Ola Berg <ol...@ports.se>]

> it appears that [functor] will need to depend on [lang] for exception 
> nesting.
> 
> hopefully, lang will not need to depend on functor. if it does, then maybe 
> it shows that the factoring has gone a bit wrong and we need to think 
> about it again.

No, I don't agree. Functors would be very useful within [lang]. 

/O


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Wednesday, December 11, 2002, at 08:39 PM, Henri Yandell wrote:

>
>
> On Wed, 11 Dec 2002, Stephen Colebourne wrote:
>
>> Thus the only viable solutions are:
>>
>> Solution (a)
>> functors in [lang]
>> [collections] depends on [lang]
>>
>> Solution (b)
>> functors in [functor]
>> [collections] depends on [functor]
>>
>> Solution (c)
>> functors in [collections]
>>
>> Any more views. Is [functor] viable??
>
> [functor] seems fine. The charter definitely pushes us towards small
> components, and this is a viable way of managing a library [with
> its own set of obvious negatives]. I'm all for the functor package as is
> in Lang being promoted to Functor [yeah, were back to patterns but with a
> better PROPOSAL].

+1

> Does it matter if [functor] and [lang] have circular dependencies? Not
> that they will.

it appears that [functor] will need to depend on [lang] for exception 
nesting.

hopefully, lang will not need to depend on functor. if it does, then maybe 
it shows that the factoring has gone a bit wrong and we need to think 
about it again.

- robert


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[Henri Yandell <ba...@generationjava.com>]

On Wed, 11 Dec 2002, Stephen Colebourne wrote:

> Thus the only viable solutions are:
>
> Solution (a)
> functors in [lang]
> [collections] depends on [lang]
>
> Solution (b)
> functors in [functor]
> [collections] depends on [functor]
>
> Solution (c)
> functors in [collections]
>
> Any more views. Is [functor] viable??

[functor] seems fine. The charter definitely pushes us towards small
components, and this is a viable way of managing a library [with
its own set of obvious negatives]. I'm all for the functor package as is
in Lang being promoted to Functor [yeah, were back to patterns but with a
better PROPOSAL].

Does it matter if [functor] and [lang] have circular dependencies? Not
that they will.

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[Stephen Colebourne <sc...@btopenworld.com>]

Rodney wrote:
> You're right, the Functors-acting-on-Collections methods don't need
> commons-collections, just java.util.  This has an added benefit of making
> the transition from [collections] to [functor] easier for us to deal with.
> We don't need to update anything in [collections], we just need to remove
> things.  We could deprecate the [collections] versions and keep them
> around (otherwise unchanged) for several releases if we wanted, both
> versions (even the already released versions of [collections]) should work
> in parallel just fine.

Unfortunately, I just checked [collections] in more detail to verify that
this would work and found far more use of functors in [collections] than I
thought. Predicate is used extensively by Filtered and Predicated
collections. There is no way that this can be easily removed.

Thus the only viable solutions are:

Solution (a)
functors in [lang]
[collections] depends on [lang]

Solution (b)
functors in [functor]
[collections] depends on [functor]

Solution (c)
functors in [collections]

Any more views. Is [functor] viable??

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[Rodney Waldhoff <rw...@apache.org>]

On Sun, 8 Dec 2002, Stephen Colebourne wrote:

> From: "Rodney Waldhoff" <rw...@apache.org>
> > On Sun, 8 Dec 2002, Stephen Colebourne wrote:
> > > Solution #3 [functor] project, that contains the functor interfaces,
> > > implementations and CollectionUtils implementations, with the
> > > collections interfaces and CollectionUtils code deprecated in favour
> > > of the functor ones.
> >
> > In this scenario, why would the CollectionUtils methods need to be
> > removed? (They'd need to be changed to use the [functor] project's
> > packaging of Transformer, Predicate et al of course.)  It makes sense to
> > me to have [functor] define the core interfaces (and where appropriate,
> > implementations), and still leave the CollectionUtils methods as functors
> > applied to collections.
>
> The reasoning is to allow [collections] to remain dependency free. I
> also think that its not a bad idea to put the code where functors
> operate on collections in [functor] - those methods only require the JDK
> collections interfaces to work ;-) Basically, functors operating on
> collections _could_ be in either component, but by being in functor the
> dependency is removed.
>

You're right, the Functors-acting-on-Collections methods don't need
commons-collections, just java.util.  This has an added benefit of making
the transition from [collections] to [functor] easier for us to deal with.
We don't need to update anything in [collections], we just need to remove
things.  We could deprecate the [collections] versions and keep them
around (otherwise unchanged) for several releases if we wanted, both
versions (even the already released versions of [collections]) should work
in parallel just fine.

>
> > > - [functor] depends on [lang]
> >
> > The o.a.c.lang.functor package is only weakly coupled with anything else
> > in o.a.c.lang:
> >
> > a) the Exception classes extend NestableException, which simply dulicates
> > functionality already available in 1.4 VMs (and not all that elegantly
> > since the API is different from that in 1.4)
> >
> > b) FactoryUtils uses a single, simple method of SerializationUtils to
> > perform a serialize/deserialize copy.
>
> Hmmm, this opens up the possibility of three non-dependent components which
> would be good I suppose.
>
> (I guess this in solution #6)
>

I think I'm liking that approach more and more.

 - Rod

> Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Rodney Waldhoff" <rw...@apache.org>
> On Sun, 8 Dec 2002, Stephen Colebourne wrote:
> > Solution #3
> > [functor] project, that contains the functor interfaces, implementations
and
> > CollectionUtils implementations, with the collections interfaces and
> > CollectionUtils code deprecated in favour of the functor ones.
>
> In this scenario, why would the CollectionUtils methods need to be
> removed? (They'd need to be changed to use the [functor] project's
> packaging of Transformer, Predicate et al of course.)  It makes sense to
> me to have [functor] define the core interfaces (and where appropriate,
> implementations), and still leave the CollectionUtils methods as functors
> applied to collections.

The reasoning is to allow [collections] to remain dependency free. I also
think that its not a bad idea to put the code where functors operate on
collections in [functor] - those methods only require the JDK collections
interfaces to work ;-) Basically, functors operating on collections _could_
be in either component, but by being in functor the dependency is removed.


> > - [functor] depends on [lang]
>
> The o.a.c.lang.functor package is only weakly coupled with anything else
> in o.a.c.lang:
>
> a) the Exception classes extend NestableException, which simply dulicates
> functionality already available in 1.4 VMs (and not all that elegantly
> since the API is different from that in 1.4)
>
> b) FactoryUtils uses a single, simple method of SerializationUtils to
> perform a serialize/deserialize copy.

Hmmm, this opens up the possibility of three non-dependent components which
would be good I suppose.

(I guess this in solution #6)
Stephen



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections][lang] Functors, pre-vote

[Rodney Waldhoff <rw...@apache.org>]

On Sun, 8 Dec 2002, Stephen Colebourne wrote:

> Solution #3
> [functor] project, that contains the functor interfaces, implementations and
> CollectionUtils implementations, with the collections interfaces and
> CollectionUtils code deprecated in favour of the functor ones.

In this scenario, why would the CollectionUtils methods need to be
removed? (They'd need to be changed to use the [functor] project's
packaging of Transformer, Predicate et al of course.)  It makes sense to
me to have [functor] define the core interfaces (and where appropriate,
implementations), and still leave the CollectionUtils methods as functors
applied to collections.

> - [functor] depends on [lang]

The o.a.c.lang.functor package is only weakly coupled with anything else
in o.a.c.lang:

a) the Exception classes extend NestableException, which simply dulicates
functionality already available in 1.4 VMs (and not all that elegantly
since the API is different from that in 1.4)

b) FactoryUtils uses a single, simple method of SerializationUtils to
perform a serialize/deserialize copy.

It would not be strictly necessary for [functor] to depend upon [lang],
and this would remove the following drawbacks as well:

> - Functor users, like [io], need to depend on [functor] and [lang]

> - Causes problems if [lang] wants to use a functor


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>