Mike, I believe I understand the definition of "truly immutable" you are using here, and what it means in the JVM as far as synchronization of object values across threads.
What seems a bit odd is to use the phrase "truly immutable" to describe something that is clearly mutable, or at least it is by the definition of "mutable": "can be modified after construction", which PersistentVector and others can be. Thanks, Andy On Tue, May 6, 2014 at 6:20 PM, Mike Fikes <mikefi...@me.com> wrote: > Hi Andy, > > Marking Java fields as final has semantics with respect to threading, > defined in the JLS in section 17.5 ( > http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#17.5) > > If you do this, then it makes it possible to freely pass a "truly" > immutable object instance to another thread and be guaranteed that that > other thread will see the value initialized for that field in the > constructor. > > If you don't do this, then the object can still be "effectively" > immutable, which essentially means that you can pass the object to another > thread, so long as you do it in a safe manner (using a volatile, or some > synchronization mechanism). > > JCIP helps clarify all of this unfortunately complex topic. > > The important thing (and key to Closure), is that, if you are implementing > the class that you want to be immutable, then if you can mark everything as > final, then you truly achieve the benefits immutability give you with > concurrency (in short, you need no synchronization whatsoever). If you fail > to do this, then you have "effective" immutability, which is good, but > complex and comes with caveats on how you can safely pass objects between > threads. > > JCIP is a great book. But, the approach taken by Clojure makes a lot of > the complicated concerns covered by the book largely ignorable, IMHO. > > On Tuesday, May 6, 2014 8:35:43 PM UTC-4, Andy Fingerhut wrote: > >> Alex, I may be unfamiliar with the definitions of truly immutable and >> effectively immutable being used here, but if I can mutate the contents of >> a Java Object array that is a final field after an object is constructed, >> does it really matter that much if it is final? It is trivially easy to >> mutate using Java access. Here is the example that I mentioned earlier in >> this thread, copied here for convenience: >> >> user=> (def v [1 2 3]) >> #'user/v >> user=> (class v) >> clojure.lang.PersistentVector >> user=> v >> [1 2 3] >> user=> (aset (.tail v) 1 -2) >> -2 >> user=> v >> [1 -2 3] >> >> Andy >> >> >> On Tue, May 6, 2014 at 4:49 PM, Alex Miller <al...@puredanger.com> wrote: >> >>> The Clojure persistent data structures are truly immutable - all fields >>> are final and referred objects are not mutated after construction so that >>> freeze occurs. One obvious exception are the transient variants ( >>> http://clojure.org/transients). You can look at the code in >>> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - >>> any of the Persistent*.java. >>> >>> >>> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote: >>>> >>>> Are the persistent immutable data structures in Clojure "truly" >>>> immutable (using final fields, relying on constructor freezing), or are >>>> they mean to be merely effectively immutable (as defined in JICP)? >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
