Matt Benson wrote:
What [functor] needs is the confidence to stand up and say
"hey, come and use me, here's what I offer".
I somewhat resent the implication that I and others might be trying to buffalo
> [functor] into "proper" status, but I'm known for paranoia, so forgive me
> if I've read more into that statement than was intended.
Nope, just saying that [functor] looks finished as is, and could make a
case for being proper separate to this discsssion.
Now look at the other angle - what do users of
[collections] want? Its additional implementations of JCF
collections, and new related collection interfaces. In many
ways, its a historic oddity that [collections] has any
functor-like stuff at all. Many (most) users of collections
are not interested in the functor-type stuff I'd suggest.
IMO this sounds like a reason to remove functor concerns from
> [collections] entirely.
Thats what I was driving at with this and the next section. In my time
in [collections] I inherited the functor APIs. I always thought of them
as slightly detached, but they had become inseparable from what
[collections] is.
From whence did the bean-collections move?
The collections in [bean-collections] were formerly part of [collections].
We should be clear that there are no perfect solutions here. However, I
will note that [collections] is too large a jar file in Kb for some
people now.
> As I see it, the functors in [collections] are a subset of those
> in [functor].
Agreed. But the [collections] ones have more history and usage in user-land.
> Presuming we allow both sets to stand, this still
> does not address the concern voiced by James Carman: a [functor]
> UnaryFunctor--for any of which an analogous interface WILL exist in
> [collections]--is not readily usable in [collections]. I still
> don't see what the big deal is about optional dependencies, so can
> we agree that [functor] could provide adapters to [collections]'s
> functors when appropriate, creating an OPTIONAL dependency on
> [collections] from [functor] (i.e. required only when the adapter
> code is used)?
This is the deeper question, of which there is no perfect solution.
One approach is the optional dependency as described. The problem is
that humans find this hard to grasp and dependency analysers don't
follow it at all.
Another solution is to create a small binding jar [functor-collections]
that links the two projects. This is clear to users and tools, but also
a bit of a hassle.
Yet another solution is to copy the interfaces from [collections] into
[functor] without changing the package names. This sounds mad at first,
but has been done before with [beanutils]. The key point is that the
original project has to commit to never change any aspect of the copied
files, which in this case would be fine. The only downside with this
approach is if [collections] and [functor] ended up in different
class-loaders, because you'd then have two copies of the [collections]
functors, one in the collections jar and one in the functor jar.
This final approach works in reverse, as I mentioned in my last reply.
If [collections-ng] included the key [functor] APIs.
Overall though, I still haven't really seen a compelling argument as to
why [functor] can't include collection implementations directly based on
the JDK List/Set/Map interfaces (leaving any [collections-ng] without
any functors or functor-based collections).
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
