There are a couple of problems with that code far as generic reuse is concerned. First, calling code must know what kind of target collection it wants before calling map. The higher kinded solution allows calling code to remain generic and oblivious to what is being mapped. If the calling code is to remain generic, then it too must pass a collection from its caller. That requirement goes on up to a point where the buck stops - but that spot in the code may not care that there's a map happening deep in the bowels of what it's calling. So creating a new, emtpy collection at that spot may seem like a pretty arbitrary requirement. See for example the type safe form of Collections.toArray where the need to pass in an array of the correct type is driven by how type erasure interacts with Java's covariant arrays to create what feels pretty arbitrary to the caller.
Second, this code introduces a shared mutable object into a realm that shouldn't need to mutate anything. That means this code is constrained to creating only mutable collections and that working with this code in a parallel code base has become trickier. Finally, the constraint that the target be a Collection means that this map is unsuitable for a great many other Mappable constructs that don't really fit the Collection mold. Let me also add that a small example suitable to motivate a paper or a mailing list post can often lead people to think that the proposed solution only fits the motivating problem. Higher kinded types fit a lot more than just map. For instance, here's paper http://cs.nju.edu.cn/boyland/ftjp/paper_15.pdf that proposes higher kinded types (which they call type constructor parametrization) for Java and motivates it not only with some operations on Collections, but also with a Visitor to evaluate a language. On Dec 27, 8:56 pm, Alexey Zinger <[email protected]> wrote: > James, > > Thank you for your explanation. This was very helpful for me to get a better > understanding of some of the confusing nomenclature between Java and Scala, > as did the Moors, Piessens, Odersky paper that's been linked to previously > (http://www.cs.kuleuven.be/~adriaan/files/higher.pdf). > > I believe I understand your example, but I'm not sure I see the major gain. > After all, the following is legal Java: > > public class Util > { > public static <S, T> void map(Iterable<? extends S> source, Collection<? > super T> target, Transformer<S, T> trans) > { > for(S val : source) > target.add(trans.transform(val)); > } > > } > > Yes, its clients will have to use perhaps 3 lines instead of 1. Is that what > this is really all about, or am I missing something? > > Alexey > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
