The Alther and Cremet paper definitely brought back some memories of trying to deal with algebraic types and binary methods in Java. However, in practice, while unpleasant, I was able to solve the problems at hand, usually with the sacrifices akin to what you mention about my example. One thing that comes to mind is that perhaps languages like Scala would be very useful as the equivalent of a very powerful drill press when the cordless drill is not up to the job. In other words, provided we have good Java-Scala interoperability, I see myself "upgrading" to Scala in specific situations, when Java itself won't do, but not as a 100% replacement.
Alexey --- On Sun, 12/28/08, James Iry <[email protected]> wrote: > From: James Iry <[email protected]> > Subject: [The Java Posse] Re: Scala for the enterprise? > To: "The Java Posse" <[email protected]> > Date: Sunday, December 28, 2008, 11:30 AM > 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 -~----------~----~----~----~------~----~------~--~---
