[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

Igor Stasenko siguctua at gmail.com
Wed Jun 13 12:10:03 UTC 2012


On 13 June 2012 09:41, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 2012-06-13, at 05:27, Igor Stasenko wrote:
>
>> Another (open) question, is how to deal with immutability in presence
>> of  become, i.e.:
>>
>> mutableCopy := immutableObject shallowCopy.
>> immutableObject becomeForward: mutableCopy.
>>
>> such kind of things making immutability useless for protecting some
>> critical parts of object memory,
>> like preventing modification of compiled method literals:
>>  yes you cannot change the immutable object, but you can replace all
>> pointers to it with it's own mutable copy, which is equivalent to
>> making it mutable again.
>
>
> Why should the VM allow become of an immutable object?
>

You can disallow this. But you can only make it harder: i can do it
manually - take all objects pointing to immutable one and replace the
pointer to it with it's mutable copy. And it is completely legal,
except that it will be a bit harder, since done not by primitive.

Disallowing #become on immutables raising many additional questions:

what is your action when you need to migrate instances of a class due
to it's reshaping, while some of them are immutable?
(I bet there is be many other examples, when this will break existing
traditional schemes, like working
with proxies etc).

I don't wanna spread FUD.. just want to make sure that we ready to
answer for every such question.


> - Bert -

-- 
Best regards,
Igor Stasenko.


More information about the Vm-dev mailing list