James Carman wrote:
On Tue, May 12, 2009 at 7:29 AM, Stephen Colebourne
<scolebou...@btopenworld.com> wrote:
The 'functors' in [collections] and [functor] are very different:
I would argue that they're not inherently different, though. A
Predicate in collections-speak is the same thing as a UnaryPredicate
in functor-speak. They are interfaces that have one method taking an
object (of a particular type in the "new" stuff) and returns
true/false. Likewise, a Closure is a UnaryProcedure and a Transformer
is a UnaryFunction. There really should be no need to come up with a
new concept here, IMHO. What's wrong with having a very simple API
jar from functor (which includes the no-arg, unary, and binary
versions of the three interfaces)? These interfaces haven't changed
(nor can they by definition) for a long time aside from us now adding
generics to the mix, but that's a non-issue since we're talking about
making these changes in the generified collections library.
This is where Henri's points about innovation come in.
My aim is, in some ways, to stop innovation. But only on those projects
that are widely used and stable.
The generified collections library is more like a new project -
[collections-ng] - and as such should do what ever innovation its
authors feel like (and the success or failure of those choices is part
of that innovation).
So, I don't have any philosphical objection to a [collecions-ng] that
sets out to "reboot" [collections] (which includes a new package, and a
clear public mission statement to break compatibility and be different).
Note that I strongly believe that it should actually be a new commons
project, completely parallel to the original.
Personally, I'd still advise against adding any dependencies whatsoever
even a small API jar. Thats because going from zero to one dependency is
a big deal. However, that decision is the choice of the new authors of
[collections-ng]. I'll outline one way that the dependency can be
avoided (copying it) in my other reply.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
