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

[Bert Freudenberg]

On 2012-06-13, at 14:10, Igor Stasenko wrote:

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

Okay, I guess you're right. (although the solution would be "don't do that" rather than "immutability is useless").

But become would not replace a reference in an immutable object. Which is a major point of immutable objects: all objects "inside" an immutable object are immutable, too. (although I think even that was up for discussion last time we had this conversation)

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

Interesting case. One solution would be to simply fail the class reshape if there are immutable instances. One would have to do a mutable copy + become.

> (I bet there is be many other examples, when this will break existing
> traditional schemes, like working
> with proxies etc).

It would have to be used sparingly and with care, sure.

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


Yep. That's why we're discussing :)

- Bert -