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