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

[Igor Stasenko]

On 13 June 2012 16:32, Andreas Raab <Andreas.Raab at gmx.de> wrote:
>
> Igor wrote:
>
> 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')?
>
>
> Absolutely nothing. Why should it? Assuming that all your "pointers to immutable a" are mutable themselves you can absolutely change them. Go right ahead. You *can* replace an immutable by a mutable object, it's trivial:
>
>   value := Object new beImmutable.
>   value := value asMutableCopy.
>
> See, done. So where is the problem? Whether you write it like that or whether you write it like here:
>
>   value := Object new beImmutable.
>   value := value become: value asMutableCopy.
>
> is entirely irrelevant. It doesn't change the fact that the original object is still immutable after the operation and that's the only thing that counts for the VM operation. Of course the following would be somewhat different:
>
>   immutable := (#abc -> Object new) asImmutable.
>   value := immutable value beImmutable.                   "making the value immutable"
>   value := value become: value asMutableCopy.
>
> In this case, the following assertions should hold:
>
>   self deny: value == immutable value. "assoc was frozen, no changing its value"
>   self assert: value isMutable.
>   self deny: immutable value isImmutable.
>
> So this all works out just fine. BTW, I think that discussing the use of become for hacking into the system is beyond the scope of this discussion. Become is used in very few situations and its semantics are necessarily such that one can do bad things with it. Duly noted, let's move on.
>
>
>> 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.
>
>
> I absolutely do. There were several situations (for example in Croquet and at Teleplace) where we changed our designs to the worse merely due to the lack of immutability support. The main thing that immutability fixes is to prevent accidental modifications of objects thought to be immutable (method literals for example), which when they happen are *extremely* hard to find.

I finding this very weak argument. You are talking about developing
project and bug fixing.. Yes i agree immutability can be useful for
debugging. But for deployed & well tested applications?
Once you found all bugs, and deploy your application, do you really
think it is worth paying the price for checking all  write operations,
when you already made sure that your app will behave correctly?

This is the same scenario as if i build debug version of VM which has
many assertions and additional checks enabled,
so i can find what is going on.
But when you deploy, you disable them for obvious reason -
performance, and because they don't needed once you prove that all
preconditions hold, no matter what your code does.

As for *extremely* hard to find, i think first thing which you should
address in such cases is the complexity
of your application, to always be able to reason about it's behavior
and make sure it behaves "deterministically", because if software
grows too large up to the point that you need such kind of crutches to
figure out what's happening, immutability alone doesn't solve your
problems, it can only indicate that you have a problems with your
design.

> But it also gives rise to many other interesting techniques (read-only transactions etc).
>

Look, we have completely open system in our hands. Do you think it is
impossible to implement certain things w/o immutability?

> Cheers,
>   - Andreas
>
>
> 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.
>
>
>
>
> --
> NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
> Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
>



-- 
Best regards,
Igor Stasenko.