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. > -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
