commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [COLLECTIONS] TransformedCollection generic signature seems wrong
Date Tue, 19 Oct 2010 18:14:09 GMT
On 19 October 2010 14:44, Matt Benson <> wrote:
> On Oct 19, 2010, at 7:00 AM, sebb wrote:
>> I'm trying to get my head round the generic signature of the
>> decorate() method, for example in TransformedCollection:
>> public static <E> Collection<E> decorate(Collection<E> coll,
>> Transformer<? super E, ? extends E> transformer)
>> This does not seem to allow one to transform String into Integer (or
>> vice-versa) without ignoring type-safety warnings.
>> I would expect to be able to do something like:
>> Collection<String> cs = ...
>> Transformer<String,Integer> s2i = ...
>> Collection<Integer> ci = TransformedCollection(cs, s2i);
>> But the signature does not allow this.
>> I think the signature should probably look like:
>> public static <I, O> Collection<O> decorate(Collection<I> coll,
>> Transformer<I, O> transformer)
>> where I and O stand for Input and Output, as in the Transformer API.
>> Or have I misunderstood the purpose of the method?
> Hi, Seb--the problem with all the Transformed* classes in [collections] is that, in order
to implement the original Java collections APIs, there must be some relationship between the
input and output parameters.  The description of TransformedCollection is that is transforms
objects that are added.  Using your proposed decorate signature above, you now have a Collection
of type O, which is fine--except now you cannot add objects of type I without ignoring *their*
actual types at RT.  So I guess you might say you have misunderstood the purpose of the method.
 The whole Transformed* "motif" in [collections] didn't, IMO, translate well to generics.
 This is what led me to reimplement Map transformation by the SplitMap approach, to decouple
the read/write sides of the interface.  I'm not sure how a similar approach would work for
Collections, though I don't suppose there's any real difference.

I see, I'd not considered adding further source types to the
transformed output. Drat.

It does not seem to be possible to use the generic interface for
anything other than trivial conversion, unless one treats everything
as Objects, which rather defeats the purpose.

> -Matt
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message