Igor wrote:
On 13 June 2012 15:16, Andreas Raab Andreas.Raab@gmx.de wrote:
On 13 June 2012 09:41, Bert Freudenberg bert@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. But it also gives rise to many other interesting techniques (read-only transactions etc).
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.