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

[Andreas Raab]

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. 
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.
> 
        
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120613/c54cb1b9/attachment-0003.htm