On Sun, Mar 24, 2013 at 6:59 PM, Andy Fingerhut <andy.finger...@gmail.com>wrote:
> > > On Sun, Mar 24, 2013 at 11:04 AM, Jim - FooBar(); <jimpil1...@gmail.com>wrote: > >> On 24/03/13 17:49, Shantanu Kumar wrote: >> >>> In this case, making the type immutable is probably encouraged but not >>> mandatory >>> >> >> yes true, it's not enforced or anything like that, but I'd say it is more >> than just 'encouraged'... what would be the point of using clojure's >> reference types with something mutable? there is nothing to be gained from >> that, is there? the indirection of vars/refs only makes true sense when >> dealing with values and pure functions... >> > > It might not be obvious at first, but Clojure's "immutable" types are > *not* immutable in the sense of "they cannot be modified in place from > within the JVM", but only in the sense of "they cannot be modified in place > by using Clojure's functions alone on them". This surprised me at first > when I learned it. For example, try this at a REPL: > > 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] > > So Clojure's built-in collection types are immutable in the sense of "they > are immutable if you don't do anything that mutates them". > > In the very same sense, *any* Java Object can potentially be immutable -- > just don't do anything that mutates it. > > I agree that there are some types that are much easier to avoid mutating > than others, because it is made inconvenient to do so. However, if you are > willing to, and have JVM permissions to, use reflection in certain ways, > you can even modify private fields of an object. > Famously, that includes being able to use setAccessible and then mutate a (nominally immutable, final, and rock-solid) java.lang.String. Any programming language sufficiently powerful to be very useful makes it possible to shoot yourself in the foot with it, if you're sufficiently determined. As a certain science fiction author once put it, "it's a poor nuclear blaster that *can't* point both ways". That said, I *am* *somewhat* surprised that clojure.lang.PersistentVector exposes a mutable internal representation via a *public* Java API. Incidentally, I can see nesting alterable things in Clojure ... for example, an atom holding a ref. As long as the inner alterable thing uses object identity as its equality test, this should be safe, and it arises naturally if an atom (rather than a function parameter, say, or something else) turns out to be the best way to implement something that decides "which ref transaction X fiddles with". -- -- 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/groups/opt_out.
