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 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:
http://rmod.inria.fr/web/publications/bib?query=Arna10a&display=abstract
The idea is that we hacked the VM to have references-as-objects that can override behaviour transparently.
Marcus