commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [all] Core library dependencies [was COLLECTIONS 3.3 release]
Date Tue, 12 May 2009 22:56:40 GMT
James Carman wrote:
> On Tue, May 12, 2009 at 7:29 AM, Stephen Colebourne
> <scolebourne@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message