

Clarification of Immutable and Mutable Objects in Scala - zacharydanger
http://leftnode.com/entry/clarification-of-immutable-and-mutable-objects-in-scala

======
tomp
There's quite a bit of confusion in this article... Maybe the author "gets"
it, but (s)he sure doesn't explain it well.

The way I see it: there are two kinds of entities here: variables, and objects
these variables reference/point to. If a variable is mutable, it can be made
to reference a different object. If it is immutable, it will always reference
the same object, the one it initially references. If an object is mutable, its
properties/contents can be changed (e.g. adding to an array). If it is
immutable, it will always remain the same as it was when it was initialized.

~~~
DannoHung
What's actually more useful to get into is _why_ you want to use immutable or
mutable data in certain situations.

If the data you have is not going to be written to often (not never, mind) but
will be shared widely, then it makes sense to use an immutable object (or
structure) which will allow the shared aspects to vary locally, but minimize
copying and redundant memory usage globally.

If you're going the other way, frequently written to and not shared widely,
then mutable structures have advantages since mutation can be faster than
partial reconstruction.

Not to say that this always holds true, but it's a decent rule of thumb and
can help you make sane choices when initially selecting collections.

