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.


Reply via email to