commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [COLLECTIONS] TransformedCollection generic signature seems wrong
Date Wed, 20 Oct 2010 15:16:38 GMT

On Oct 19, 2010, at 1:14 PM, sebb wrote:

> On 19 October 2010 14:44, Matt Benson <gudnabrsam@gmail.com> 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.
> 

Glad to have a corroborating second opinion.  :)

-Matt

>> -Matt
>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message