Norbert,

On Wed, Jan 25, 2017 at 3:36 PM, Norbert Hartl <norb...@hartl.name> wrote:

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

Reply via email to