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

[Andreas Raab]

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

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120613/261cf435/attachment-0001.htm