I guess the elephant in the room is mutability. Whereas the Scala code I quoted will take an immutable map and result in an immutable map, your fantom equivalent is obviously relying on externally visible mutability to provide equivalent behaviour. I certainly wouldn't feel comfortable passing this on to multiple other threads.
Does Fantom have some form of map builder available, or a way of pinning down this map once constructed without incurring the cost of copying it to a dedicated immutable collection? For some of the larger data sets I need to work on, the performance cost of cloning to ensure thread-safety would be a deal breaking concern. 2011/11/24 Cédric Beust ♔ <[email protected]> > > > On Thu, Nov 24, 2011 at 1:28 AM, Kevin Wright <[email protected]>wrote: > >> >> This is all 100% safe and statically typed, and is made possible by the >> "scary" CanBuildFrom implicit parameter that Stephen mention in his article. >> >> I don't believe that Fantom can do this >> > > It depends on what you mean by "this", but the answer is that Fantom > certainly can (as can all these other languages I'm sure). I'm providing > the code below and not here since I don't want to turn this into a Scala > vs/ Fantom debate, which is not the point I'm trying to make here. In this > particular example, you're just morphing one map into another, which is > really trivial. Admittedly, Fantom requires to declare a new map and then > adding the new content to that map, but you will probably do that in Scala > as well if you want to reuse that result (which I bet you would in a real > program and not a code golf). > > > >> , not least because it doesn't have highly-optimised collection types >> such as BitSet >> > > Maybe, maybe not. Optimized libraries are a separate topic from language > comparisons. > > The bottom line here, again, is that implicit CanBuildFroms and other > subtleties are a very specific implementation detail in Scala that are not > necessary for languages that followed a different path to build their type > system. > > By the way, I don't think the Liskov Substitution Principle is applicable > here since a function taking a Map[Int,String] will certainly not be happy > if you pass it a Map[String,String]. > > > >> , it doesn't consider Maps to subclass collections of pairs >> > > True, but this seems is a collection design choice, not a language feature > (I like it, personally). > > >> , and it doesn't support creation of your own paramaterised collection >> types. So far as I'm aware, Scala is the only language in existence that >> directly supports such a scheme (though I imagine it would be totally >> possible to duplicate using something like Lisp macros) >> > > I don't think so but if I misunderstood your point, feel free to clarify. > > Finally, the code to morph the map: > > aMap := [1:"x", 2:"y", 3:"z"] > // Create an empty map > map2 := [:] > // Create the map ["1":"x", "2":"y", "3":"y"] > aMap.each |v,k| { map2[k.toStr] = v } > // map2 is now a [Str:Str] > echo(map2) > > -- > Cédric > > -- 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.
