In certain cases all we want to do is ensure the container is not modifiable but don�t mind access to the held objects within. if the internal data is immutable (e.g. a representation of an error) then we don�t care if they have access to this data but we may care that they modify the collection that holds these objects. You then need to weigh in with a pro/con of using unmodifiable collections versus a copy; most of the time a copy is all you need as the collections will be small.

If the context requires for some (odd) reason complete immutability and you�re happy to pay the price in terms of space/time or additional complexity then there are other solutions from deepCopy, to something like Worlds (http://www.vpri.org/pdf/tr2011001_final_worlds.pdf , http://www.vpri.org/pdf/m2013002_experiments.pdf ) or maybe some weird use of software transactional memory.

The point is though that there are valid cases where an immutable container is all you want; Java provides this as a library out of the box, if developers mis-use it then it�s not an issue with the language but rather an OO design flaw by the programmer as was previously mentioned. By the same token if Smalltalk developers only use #copy to achieve similar semantics then the Java solution is more elegant in terms of performance but potentially confusing with regards to the change in behaviour of the returned collection (can�t mutate the collection now which could break contract of collection).

On 14 May 2014, at 1:02 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

2014-05-14 12:50 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:

But how well "unmodifiable" collection is?
Should it protect also from modifying the items themselves? Or any object(s) accessible through items? Or any objects accessible through all objects accessible through items?
Because without propagating immutability how you cannot prove that you actually made things "safe"?
There was a work by Jean-Baptiste exploring that direction, by introducing special kind of references (immutable references).. which is a special view on object that does not allows its modification and also has an option to propagate same kind of property on all references it may give away.

This is done at VM level, sure thing.. and sure thing there is a performance cost..
but again, if you so desperately need "safety", just making immutable collections is not a solution. It is much more involved :)

Even a veryDeepCopy (sic...) would not be enough for safety.

We are dynamic and the behavior can change at any moment.

So you'd need to also duplicate the whole class hierarchy of each and every object in the graph.

Or lock if you prefer lock to copy, but problem remains the same...

--
Best regards,
Igor Stasenko.