Norbert, On Wed, Jan 25, 2017 at 3:36 PM, Norbert Hartl <norbert@hartl.name> wrote:
Clément,
Am 25.01.2017 um 13:54 schrieb Clément Bera <bera.clement@gmail.com>:
On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <norbert@hartl.name> wro te:
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.
Well, when I introduced the code I thought someone would build a ModificationTracker framework... I think there should be a modification tracker framework that throws an exception only if no program is registered to handle the modification failure. No exception should be thrown in the generic case.
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.
Overall, you need to: - change the code of all numbered primitives mutating objects (such as at:put:) so that when they fail because of a read-only object they call the modification tracker framework. - add the call to the modification tracker framework from the #attemptToAssign:withIndex: call-back. - build a Modification tracker framework where external programs can easily register themselves to catch modification on specific objects or all instances of a specific class. Programs tracking modifications should be able to temporarily make the object writable, perform the modification and make it read-only again. You can check the VisualWork implementation (check for example the fall-back code of #at:put: and what it calls) and the comment I wrote in #attemptToAssign:withIndex: to get inspired. If you do something like that, please, *please*, please contribute it back to the base Pharo image. Thank you for experimenting with read-only objects. Don't hesitate to contact me if you have issues or questions.
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