I was more thinking of the concepts. I agree this kind of stuff
should move into functor.
On Mon, Jun 8, 2009 at 8:56 AM, Matt Benson<gudnabr...@yahoo.com> wrote:
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
