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

[Igor Stasenko]

On 13 June 2012 15:16, Andreas Raab <Andreas.Raab at gmx.de> 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.
>
>
> You are confusing something here. Become is just a "fancier form" of assignment that you could in fact write without a primitive by enumerating all the references to an object. If you keep that in mind it is obvious that since assigning an immutable *to* a variable is never a problem using become *with* an immutable as argument is neither since in both cases the immutable remains immutable.
>

But you just make it harder.. what prevents me from modifying all
pointers to immutable(a) which holds a pointer to target immutable(t),
 by mutable object (b) with replaced references to mutable (t')?

> The real question that arises is whether become should be allowed to change the *contents* of an immutable object. Personally, I think it should not, but this has some side effects that require fixing such as class migration which really should have a separate primitive to update its instances after reshape - the rules for this *should* include changing immutables unless you want to change the system to deal with multiple concurrent class versions (much pain down that path).
>

This is where i usually stop. IMO this is already showing too much
costs (to my taste) of introducing such restrictions and maintaining
them. I would ask first, is this worth an effort, if it so costly in
terms of implementation?
In theory, of course we can enforce anything, but in practice that
means a lot of complex code with many checks at VM side.. This is not
what i like to see in a first place, especially knowing that Squeak
lived well so far without any immutability and it does not feels like
we miss it badly.

For me, if we introduce some feature or want to enforce certain
behavior, then there should be very strong reason
for doing so, with benefits which clearly outweigh the costs and
making some things easier to do, like with arbitrary properties slot
- there's very little additional complexity in VM side, and very
simple to use at language side, replacing many crippling schemes ,
like properties in Morphic , Dependents in Object etc.
In contrast, an immutables adds another dimension of complexity to
already complex soup in both VM and language sides, and benefits are
not so clear, as to me.

> 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?
>
>
> Class migration should really have its own primitive. If it had, much pain could be avoided in migrating classes (see comments in ClassBuilder>>update:to:). And then one could decide on the proper policy to use for immutables.
>
> Cheers,
>   - Andreas
>
>
> (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.
>
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>



-- 
Best regards,
Igor Stasenko.