--- On Tue, 5/5/09, Stephen Colebourne <scolebou...@btopenworld.com> wrote:
> From: Stephen Colebourne <scolebou...@btopenworld.com>
> Subject: Re: [COLLECTIONS] 3.3 release
> To: "Commons Developers List" <dev@commons.apache.org>
> Date: Tuesday, May 5, 2009, 4:37 PM
>
> Matt Benson wrote:
> > --- On Tue, 5/5/09, James Carman <ja...@carmanconsulting.com>
> wrote:
> >> I'm trying to remember myself! :) I would
> think
> >> collections, since
> >> that's what this email was regarding. Is
> there a
> >> branch that gets rid
> >> of Transformer, Closure, and Predicate from
> collections and
> >> instead
> >> uses Functor's versions of these concepts?
> That's
> >> what I'd like to
> >> see (aside from the fact that I'd have to rewrite
> all my
> >> nifty
> >> transformers).
> >
> > That subject probably requires a debate. Stephen
> didn't want to completely switch to [functor].
>
> I think its really important that [collections] has no
> dependencies. As part of that, I'd also suggest that
> [functor] shouldn't have dependencies.
>
> While I understand the arguments of just picking up another
> jar if your using it, of tools like maven, and of eating dog
> food, when push comes to shove, I believe that one of the
> core conceptual attributes of [collections] is that it
> stands alone. The list archives contains more detailed
> discussion on this for those wanting to hunt it down ;-)
>
> Given that I am removed from the coding aspects of this
> these days, I won't -1 any decisions on this. But I will
> register that I believe my position very strongly.
>
I feel differently--how many times do we need to duplicate code that does the
same damned thing amongst the various components? For example, we've now added
MethodUtils to [lang], but [collections] has its own set of code supporting
InvokerTransformer. [functor] doesn't have an analogous function because it
seemed to me silly to keep rewriting and/or copying the necessary code. IMHO
we of the Commons need to establish an approach for "mixin" components,
optional dependencies, svn externals, something, to avoid doing this again and
again and again.
br,
Matt
> Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
