Kevin, you know that people do manage with mutable values as if they
were immutable pretty often. I actually only found out that
java.util.Date was mutable recently (or I forgot at some point) and
have been treating it as immutable all these years.
Perhaps there's someone maintaining some code I wrote who is cursing
me now for relying on Date being immutable, I don't know.
Even without that ignorance, not changing values you don't 'own' can
work, just as in C you free() only values you 'own'. Defensive
copying isn't actually necessary. All that said, I prefer the
guarantees immutability can give you, but without immutability I
wouldn't automatically start copying everything around, making method
calls O(n) unnecessarily.
On Thu, Nov 24, 2011 at 5:01 PM, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> 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 ♔ <ced...@beust.com>
>>
>>
>> On Thu, Nov 24, 2011 at 1:28 AM, Kevin Wright <kev.lee.wri...@gmail.com>
>> 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 javaposse@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
