Clément, > Am 25.01.2017 um 13:54 schrieb Clément Bera <bera.clem...@gmail.com>: > > > > On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <norb...@hartl.name > <mailto:norb...@hartl.name>> wrote: > Does anyone know the state of immutability support in vm and image? The > latest vm downloadable is compiled with > > IMMUTABILITY=1 > > (Esteban said that). When I open a pharo6 image with this VM and do: > > ASUser new > setIsReadOnlyObject: true; > name: 'foo' > > with > > ASUser>>#name: arg1 > name := arg1 > > I don't get an exception. Is there something missing or am I not > understanding? > > Hi Norbert, > > Thank you very much for looking read-only objects. > > When mutating an instance variable, the VM triggers a call-back that by > default does nothing. In your case, running your code does not raise an > exception but the object should not be modified either. If you want an > exception, you need to change the call-back code, i.e., the method > Object>>#attemptToAssign: value withIndex: index. For example, you could > write: > > Object>>#attemptToAssign: value withIndex: index > | process | > self notify: 'object changed !'. > process := Processor activeProcess. > [ process suspendedContext: process suspendedContext sender ] forkAt: > Processor activePriority + 1. > Processor yield. > > Then, your code should open a notification window with 'object changed', and > proceeding keeps running the code without mutating the object. > thank you very much for the explanation. What was the rationale behind doing nothing as default? I can see there is two interpretations of read-only. One being just don't modify the object the other being throwing an exception when an attempt to modify is made. I think that having an exception thrown would make it easier to write code using it. I don't want to monkey patch Object but still make this general applicable.
> One needs to build a ModificationTracker framework on top of the VM support I > introduced. Multiple things are required, like default behavior in this > call-back and in primitive failure code. I am willing to support and help > anyone willing to build such a framework, but I won't build it myself. > Modification tracking is exactly the reason why I look into it. I have two other approaches doing modification tracking. But both are inferior to an approach using read-only objects. Norbert > If you have any other questions or if you find bug don't hesitate to ask > further questions > > Best, > > PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your > system, if this is not the case it means the VM does not support read-only > objects. > > Clement > > > > > > > Norbert
