For objects - knowing if they have been modified or not could have big benefits in performance when you want to �commit� anything in your object graph to an object database. 

For collections - In NeXT / Apple WebObjects we�ve always made a distinction:
NSArray / NSMutableArray
NSSet / NSMutableSet
NSDictionary / NSMutableDictionary

Each one of these has a �mutableClone� and �immutableClone� method. 

It was this way when it was Objective-C and it remained this way when we went to Java. We never use the standard Java collections. 

The mutable classes always inherit from the immutable ones as you can see here:

http://wocommunity.org/documents/javadoc/WebObjects/5.4.2/

that makes OO sense in that the mutable versions do everything the immutable can� plus you can �add� or �remove� as well. 

Here we are only talking about the reference to objects� the objects themselves are still mutable.

In general it seems nice to make this distinction in collections. For example� suppose a �Company� has �Employees.� But somebody later is playing with the array of �employees� and wants to add one. Do they know that later someone looking at the Company will see a new employee? maybe they wouldn�t. 
Aaron Rosenzweig / Chat 'n Bike
e:  aaron@chatnbike.com  t:  (301) 956-2319
Chat 'n Bike Chat 'n Bike

On May 14, 2014, at 7:45 AM, Marcus Denker <marcus.denker@inria.fr> wrote:


On 14 May 2014, at 13:27, Carlo <snoobabk@gmail.com> wrote:

Hi

Obviously this all depends on context and what is trying to be achieved ;)
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.

We did an experiment with read-only references some time ago:


The idea is that we hacked the VM to have references-as-objects that can override behaviour transparently.

Marcus