Immutable collections and encapsulation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Immutable collections and encapsulation

Uko2
Hi,

sorry if there was already this question, but I couldn’t find it anywhere.

I’m looking in the OO-design concerns and it seams that Java guys are crazy about returning the collection that is used for state of an objects. The only acceptable option is returning it in the immutable wrapper. As far as I know, pharo does not have immutable collections (except from intervals and symbols). Are we missing something important, or there is a philosophy behind the building blocks we have now, and the design we come up while using them.

Cheers.
Uko
Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Sergi Reyner
2014-05-13 10:53 GMT+01:00 Yuriy Tymchuk <[hidden email]>:
I’m looking in the OO-design concerns and it seams that Java guys are crazy

There's your answer :D

Cheers,
Sergi 
Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Esteban A. Maringolo
In reply to this post by Uko2
I think it is more an issue of design.

If your Invoice has a collection of "Items", you shouldn't manipulate
the collection directly and instead use accessor/operator methods.

I wouldn't restrict having the option of direct manipulation of the
collection, but it is a nice thing to have covered by some LINT rules.
:)


Regards,


Esteban A. Maringolo


2014-05-13 6:53 GMT-03:00 Yuriy Tymchuk <[hidden email]>:
> Hi,
>
> sorry if there was already this question, but I couldn’t find it anywhere.
>
> I’m looking in the OO-design concerns and it seams that Java guys are crazy about returning the collection that is used for state of an objects. The only acceptable option is returning it in the immutable wrapper. As far as I know, pharo does not have immutable collections (except from intervals and symbols). Are we missing something important, or there is a philosophy behind the building blocks we have now, and the design we come up while using them.
>
> Cheers.
> Uko

Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

David Astels
Well, an issue of good OO design or not.  Returning a mutable collection breaks encapsulation. My initial question is whether the collection is simply a detail of the implementation or part of the external interface you want to expose.  If the former, hide the collection and expose operations that provide what’s truly needed. If the latter, then you might need immutable collections.

Java devs aren’t crazy… they just tend not to understand OO very well.

Dave

On May 13, 2014, at 8:28 AM, Esteban A. Maringolo <[hidden email]> wrote:

> I think it is more an issue of design.
>
> If your Invoice has a collection of "Items", you shouldn't manipulate
> the collection directly and instead use accessor/operator methods.
>
> I wouldn't restrict having the option of direct manipulation of the
> collection, but it is a nice thing to have covered by some LINT rules.
> :)
>
>
> Regards,
>
>
> Esteban A. Maringolo
>
>
> 2014-05-13 6:53 GMT-03:00 Yuriy Tymchuk <[hidden email]>:
>> Hi,
>>
>> sorry if there was already this question, but I couldn’t find it anywhere.
>>
>> I’m looking in the OO-design concerns and it seams that Java guys are crazy about returning the collection that is used for state of an objects. The only acceptable option is returning it in the immutable wrapper. As far as I know, pharo does not have immutable collections (except from intervals and symbols). Are we missing something important, or there is a philosophy behind the building blocks we have now, and the design we come up while using them.
>>
>> Cheers.
>> Uko
>


Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Uko2
Ok, I also forgot to tell my own opinion. If you as something for it’s model (or some other thing), you get it. Now it’s up to you if you want to modify it or not. The idea behind encapsulation rules is that you don’t force someone to rely on your internal data. So to allow someone add thing to your list you implement #add: method that takes one item and adds it to internal collection. But this doesn’t mean that you lock that collection from being modified when you return it. If someone want’s to write bad code he will do it anyway. One thing that you shouldn’t do is to enforce bad practices.

But this question was really to gain knowledge from experienced computer scientists/engineers.

Cheers
Uko



On 13 May 2014, at 15:47, David Astels <[hidden email]> wrote:

> Well, an issue of good OO design or not.  Returning a mutable collection breaks encapsulation. My initial question is whether the collection is simply a detail of the implementation or part of the external interface you want to expose.  If the former, hide the collection and expose operations that provide what’s truly needed. If the latter, then you might need immutable collections.
>
> Java devs aren’t crazy… they just tend not to understand OO very well.
>
> Dave
>
> On May 13, 2014, at 8:28 AM, Esteban A. Maringolo <[hidden email]> wrote:
>
>> I think it is more an issue of design.
>>
>> If your Invoice has a collection of "Items", you shouldn't manipulate
>> the collection directly and instead use accessor/operator methods.
>>
>> I wouldn't restrict having the option of direct manipulation of the
>> collection, but it is a nice thing to have covered by some LINT rules.
>> :)
>>
>>
>> Regards,
>>
>>
>> Esteban A. Maringolo
>>
>>
>> 2014-05-13 6:53 GMT-03:00 Yuriy Tymchuk <[hidden email]>:
>>> Hi,
>>>
>>> sorry if there was already this question, but I couldn’t find it anywhere.
>>>
>>> I’m looking in the OO-design concerns and it seams that Java guys are crazy about returning the collection that is used for state of an objects. The only acceptable option is returning it in the immutable wrapper. As far as I know, pharo does not have immutable collections (except from intervals and symbols). Are we missing something important, or there is a philosophy behind the building blocks we have now, and the design we come up while using them.
>>>
>>> Cheers.
>>> Uko
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Igor Stasenko
In reply to this post by David Astels
indeed. simply don't expose unwanted operations to the user.
there's many ways to do that and wrapping it is just one of it.


On 13 May 2014 15:47, David Astels <[hidden email]> wrote:
Well, an issue of good OO design or not.  Returning a mutable collection breaks encapsulation. My initial question is whether the collection is simply a detail of the implementation or part of the external interface you want to expose.  If the former, hide the collection and expose operations that provide what’s truly needed. If the latter, then you might need immutable collections.

Java devs aren’t crazy… they just tend not to understand OO very well.

Dave

On May 13, 2014, at 8:28 AM, Esteban A. Maringolo <[hidden email]> wrote:

> I think it is more an issue of design.
>
> If your Invoice has a collection of "Items", you shouldn't manipulate
> the collection directly and instead use accessor/operator methods.
>
> I wouldn't restrict having the option of direct manipulation of the
> collection, but it is a nice thing to have covered by some LINT rules.
> :)
>
>
> Regards,
>
>
> Esteban A. Maringolo
>
>
> 2014-05-13 6:53 GMT-03:00 Yuriy Tymchuk <[hidden email]>:
>> Hi,
>>
>> sorry if there was already this question, but I couldn’t find it anywhere.
>>
>> I’m looking in the OO-design concerns and it seams that Java guys are crazy about returning the collection that is used for state of an objects. The only acceptable option is returning it in the immutable wrapper. As far as I know, pharo does not have immutable collections (except from intervals and symbols). Are we missing something important, or there is a philosophy behind the building blocks we have now, and the design we come up while using them.
>>
>> Cheers.
>> Uko
>





--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

abergel
In reply to this post by Uko2
I got an interest some years ago, to see if Context-Oriented-Programming would help to have immutable collections.

Apparently, Java supports immutability at runtime (i.e., there is no class ImmutableArrayList as far as I know). So, there is no good design for immutable collections as far as I know. I read something about that on Doug Lea web page.

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 13, 2014, at 5:53 AM, Yuriy Tymchuk <[hidden email]> wrote:

> Hi,
>
> sorry if there was already this question, but I couldn’t find it anywhere.
>
> I’m looking in the OO-design concerns and it seams that Java guys are crazy about returning the collection that is used for state of an objects. The only acceptable option is returning it in the immutable wrapper. As far as I know, pharo does not have immutable collections (except from intervals and symbols). Are we missing something important, or there is a philosophy behind the building blocks we have now, and the design we come up while using them.
>
> Cheers.
> Uko


Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

abergel
In reply to this post by Uko2
Also, I know that side-effect (e.g., adding or removing an element to a collection) does not work well with type-safety. E.g., Side-effect prevents many type system from being type-safe
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 13, 2014, at 5:53 AM, Yuriy Tymchuk <[hidden email]> wrote:

> Hi,
>
> sorry if there was already this question, but I couldn’t find it anywhere.
>
> I’m looking in the OO-design concerns and it seams that Java guys are crazy about returning the collection that is used for state of an objects. The only acceptable option is returning it in the immutable wrapper. As far as I know, pharo does not have immutable collections (except from intervals and symbols). Are we missing something important, or there is a philosophy behind the building blocks we have now, and the design we come up while using them.
>
> Cheers.
> Uko


Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Jan Vrany
In reply to this post by abergel
On 13/05/14 15:50, Alexandre Bergel wrote:
> I got an interest some years ago, to see if Context-Oriented-Programming would help to have immutable collections.
>
> Apparently, Java supports immutability at runtime (i.e., there is no class ImmutableArrayList as far as I know).

Actually there is. Have a look at java.util.Collections,
java.util.Collections.UnmodifiableList/UnmodifiableRandomAccessList in
particular. Many libraries define their own immutable collections as far
as I have seen.

There's no support for object immutability in the OpenJDK-based JVMs.

Cheers, Jan

> So, there is no good design for immutable collections as far as I know. I read something about that on Doug Lea web page.
>
> Cheers,
> Alexandre
>


Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Chris Muller-3
In reply to this post by Uko2
You could answer a copy of the collection, so it won't matter
internally if they try to add to it.  Or you could wrap the collection
with operations too.

However, doing that, I suppose someone could still write, "(someObject
instVarNamed: 'internalCollection') add: junk.  So, why bother?

Writing code that does nothing more than try to "protect" your
program-state from bad code elsewhere is like inflicting static-typing
on yourself.  Easier to simply not write the bad code in the first
place.  :)

On Tue, May 13, 2014 at 4:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
> Hi,
>
> sorry if there was already this question, but I couldn’t find it anywhere.
>
> I’m looking in the OO-design concerns and it seams that Java guys are crazy about returning the collection that is used for state of an objects. The only acceptable option is returning it in the immutable wrapper. As far as I know, pharo does not have immutable collections (except from intervals and symbols). Are we missing something important, or there is a philosophy behind the building blocks we have now, and the design we come up while using them.
>
> Cheers.
> Uko

Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

abergel
In reply to this post by Jan Vrany
Well, this is not what I exactly meant:

http://www.tutorialspoint.com/java/util/collections_unmodifiablelist.htm
The class Collection define the method:
        public static <T> List<T> unmodifiableList(List<? extends T> list)

It returns an instance of List. I do not think there is a type UnmodifiedList since it is difficult to type this kind of things. I think monad helps here, but I am not expert.

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 13, 2014, at 11:19 AM, Jan Vrany <[hidden email]> wrote:

> On 13/05/14 15:50, Alexandre Bergel wrote:
>> I got an interest some years ago, to see if Context-Oriented-Programming would help to have immutable collections.
>>
>> Apparently, Java supports immutability at runtime (i.e., there is no class ImmutableArrayList as far as I know).
>
> Actually there is. Have a look at java.util.Collections, java.util.Collections.UnmodifiableList/UnmodifiableRandomAccessList in particular. Many libraries define their own immutable collections as far as I have seen.
>
> There's no support for object immutability in the OpenJDK-based JVMs.
>
> Cheers, Jan
>
>> So, there is no good design for immutable collections as far as I know. I read something about that on Doug Lea web page.
>>
>> Cheers,
>> Alexandre
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

David Astels
In reply to this post by Chris Muller-3
If someone uses your class by using instVarNamed, they deserve any pain that results. Your job is to publish a clean public interface to your class, their job is to use that interface.

On May 13, 2014, at 10:29 AM, Chris Muller <[hidden email]> wrote:

> You could answer a copy of the collection, so it won't matter
> internally if they try to add to it.  Or you could wrap the collection
> with operations too.
>
> However, doing that, I suppose someone could still write, "(someObject
> instVarNamed: 'internalCollection') add: junk.  So, why bother?
>
> Writing code that does nothing more than try to "protect" your
> program-state from bad code elsewhere is like inflicting static-typing
> on yourself.  Easier to simply not write the bad code in the first
> place.  :)
>
> On Tue, May 13, 2014 at 4:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
>> Hi,
>>
>> sorry if there was already this question, but I couldn’t find it anywhere.
>>
>> I’m looking in the OO-design concerns and it seams that Java guys are crazy about returning the collection that is used for state of an objects. The only acceptable option is returning it in the immutable wrapper. As far as I know, pharo does not have immutable collections (except from intervals and symbols). Are we missing something important, or there is a philosophy behind the building blocks we have now, and the design we come up while using them.
>>
>> Cheers.
>> Uko
>


Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Sergi Reyner
In reply to this post by Esteban A. Maringolo
2014-05-13 14:28 GMT+01:00 Esteban A. Maringolo <[hidden email]>:
I wouldn't restrict having the option of direct manipulation of the
collection, but it is a nice thing to have covered by some LINT rules.
:)

That´s what I meant, in a convoluted way, with "they are crazy". For me, Java is about restrictions on restrictions on restrictions, which in the end don´t feel like giving me any advantage. In this case, if I want to modify the returned collection it should be my business. I may have a reason to do so. Then again, Java is not a dynamic language and so on... :)

Cheers,
Sergi
Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Carlo-2
Hi

The advantage is that there is a standard library for implementing efficient unmodifiable “read-only” collections. Just because the Java ‘crowd’ have it doesn’t mean they misuse it (or that they do not understand OO); there are the odd occasions when it is useful to tighten down your interfaces and by creating a “read-only” view e.g. you want to return a list of errors while ensuring that none of your clients modify (add or remove) the underlying list. This can be (efficiently) achieved in Java by wrapping your collection in an unmodifiable list as access “reads-through” to the wrapped collection. 

My understanding is that the common idiom for Smalltalk code is to rather perform a copy of the collection (as was suggested by others), this could be very inefficient but needs to be weighed in versus introducing an unmodifiable collection that breaks the Liskov substitution principle and could potentially have confusing concurrency issues (e.g. unmodifiable collection is “read-through” which means that underlying data structure can be modified which will affect the unmodifiable collection.

On the other hand having a good implementation of persistent data structures in Smalltalk would be interesting to play with…

My 2c
Cheers
Carlo


Still, after stating all of the above, I have used Java’s unmodifiable collections to prevent clients modifying results, especially when I know there is a chain of clients that may process this collection and perhaps modify the collection.



On 13 May 2014, at 7:55 PM, Sergi Reyner <[hidden email]> wrote:

2014-05-13 14:28 GMT+01:00 Esteban A. Maringolo <[hidden email]>:
I wouldn't restrict having the option of direct manipulation of the
collection, but it is a nice thing to have covered by some LINT rules.
:)

That´s what I meant, in a convoluted way, with "they are crazy". For me, Java is about restrictions on restrictions on restrictions, which in the end don´t feel like giving me any advantage. In this case, if I want to modify the returned collection it should be my business. I may have a reason to do so. Then again, Java is not a dynamic language and so on... :)

Cheers,
Sergi

Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Carlo-2
In reply to this post by David Astels
On 13 May 2014, at 3:47 PM, David Astels <[hidden email]> wrote:
> Well, an issue of good OO design or not.  Returning a mutable collection breaks encapsulation. My initial question is whether the collection is simply a detail of the implementation or part of the external interface you want to expose. If the former, hide the collection and expose operations that provide what’s truly needed. If the latter, then you might need immutable collections.

Agree 100% with David’s comment, it’s an issue of good OO design and there are valid cases to return immutable collections.
I think most developers return internal collections, breaking encapsulation, but get away with it 99% of the time and only occasionally get burnt with a nasty bug or a deep mess.

Cheers
Carlo
Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Igor Stasenko

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 :)



--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Nicolas Cellier



2014-05-14 12:50 GMT+02:00 Igor Stasenko <[hidden email]>:

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 :)




+1
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.

Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Carlo-2
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.

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).

Cheers
Carlo


On 14 May 2014, at 1:02 PM, Nicolas Cellier <[hidden email]> wrote:

2014-05-14 12:50 GMT+02:00 Igor Stasenko <[hidden email]>:

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 :)




+1
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.


Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Marcus Denker-4

On 14 May 2014, at 13:27, Carlo <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Immutable collections and encapsulation

Aaron Rosenzweig
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:


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:  [hidden email]  t:  (301) 956-2319
Chat 'n Bike Chat 'n Bike

On May 14, 2014, at 7:45 AM, Marcus Denker <[hidden email]> wrote:


On 14 May 2014, at 13:27, Carlo <[hidden email]> 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