On Oct 19, 2010, at 1:14 PM, sebb wrote: > On 19 October 2010 14:44, Matt Benson <gudnabr...@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-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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
