James,
I refactored the comparable classes in [functor] to work just that way. I
didn't feel it was worth my personal effort to do it again in [collections]
given all the discussion around the future of [collections]' functors. Didn't
we all agree we could provide analogous functionality to that provided in
[collections] in [functor] and later deprecate the [collections] functors?
-Matt
--- On Sun, 6/7/09, James Carman <ja...@carmanconsulting.com> wrote:
> From: James Carman <ja...@carmanconsulting.com>
> Subject: [collections] ChainedTransformer...
> To: "Commons Developers List" <dev@commons.apache.org>
> Date: Sunday, June 7, 2009, 10:22 PM
> All,
>
> I thought I'd check out the collections_jdk5_branch to see
> if there
> was anything that I could tinker with. I decided to
> look into the
> functors, since that's what I'm mainly interested in.
> Immediately I
> noticed ChainedTransformer. It's declared as:
>
> public class ChainedTransformer<T> implements
> Transformer<T, T>, Serializable
>
> So, does this mean that a ChainedTransformer always has to
> have the
> same input and output types? Transformer is declared
> as:
>
> public interface Transformer<I, O> {
> public O transform(I input);
> }
>
> Shouldn't it support different input/output types?
>
> What I was thinking about would be a new way to think about
> these chains:
>
> public class ChainedTransformer<I,O> implements
> Transformer<I,O>
> {
> public ChainedTransformer(Transformer<I,O>
> initial);
> public O transform(I input);
> public <T> ChainedTransformer<I,T>
> append(Transformer<O,T> next);
> }
>
> Typically, to create a ChainedTransformer, you have to put
> your
> transformers in a collection and pass them in to create
> one. This
> way, instead of having to create a new collection, you'd
> just append
> as you go. What do you think?
>
> ---------------------------------------------------------------------
> 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
