Mutable Dates are actually the lesser evil here, it's when you try to use
the same instance SimpleDateParser on multiple simultaneous threads that
you feel the real pain. It certainly looks like something you could think
of as a pure function from String => Date, but uses non-thread-safe
internally mutable state (and possibly dragons) within...
Ironically, it's Stephen who's one of the heros in leading Java out of that
quagmire by writing joda-time. I guess this is one of the reasons why I
find it so bewildering that he's now bashing Scala. More than any other
language on the JVM which is seeing mainstream adoption, it embraces the
same ideals of immutability that he once championed, even to the point that
the core of the standard collections library builds upon the same concepts.
Granted, some of the resulting mechanisms and method signatures needed to
make it all work intuitively can seem bewildering, especially to the
newcomer. But the Typesafe team and community are working hard to hide
that necessary plumbing by default from both the Scaladoc and IDE
auto-completion.
On 24 November 2011 22:22, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
> 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.
