[Vm-dev] Re: Immutability, newspeak (was: Vm-dev post from jbaptiste.arnaud@gmail.com requires approval)

[Andreas Raab]

On 6/9/2010 5:15 PM, Eliot Miranda wrote:
>     The issue isn't "implementing" deep immutability, the issue is
>     "proving" that something is deeply immutable.
>
>
> The issue is of course both.  How one implements deep immutability /is/
> a worthy topic of discussion (as this thread demonstrates) and not
> something that can be condescended away by shifting levels.

Obviously. But what I was trying to point out is that the problem 
doesn't arise when it comes to constructing an immutable object graph 
(i.e., "implementing" deep immutability) but that the issues arise when 
you need to ensure that what you're passing along is in fact 
deep-frozen. Might have been bad terminology on my part.

>     2) Traverse the object graph to prove deep immutability.
>
> Option 2 can be written in Smalltalk without a data structure to record
> the visited set by provisionally setting the immutability bit to
> terminate the recursion, unsetting it if the attempt to freeze
> substructure failed.
>
> Further, option 2 can be implemented at instance creation time so a root
> object is only instantiated if all its parts are immutable and an
> attempt to do otherwise fails.  If one has to prove that an object is
> immutable after instantiation something is wrong.  The framework should
> support maintaining immutability throughout an object's lifetime.
>
> So trivially shallow immutability can implement deep immutability if a
> system provides no way to turn-off shallow immutability once on and if
> an object is created shallowly immutable but having only immutable
> substructure.  The issue then becomes when to allow immutability to be
> temporarily rescinded, e.g. for instance mutation on class redefinition.

All of this is exactly right, but now you're making my point ;-)
I'm *asking* for that level of support of immutability. Are we perhaps a 
little confused as to what "policy" means in this context? To me it 
means what I can build in the image with the semantics that are provided 
by the VMs implementation and primitives. And I can currently *not* 
reliably build what you describe above with the means provided (simply 
due to the fact that one can nilly-willy change the immutability bit on 
any object one likes). However, if you consider primitives part of the 
policy then indeed one could do that by ripping out the existing set of 
prims and replacing them with others.

BTW, for the records, I think I do see your point here. I think what 
you're saying is that regardless of how/when immutability is turned on 
for objects, the VM (plugin) support is useful to have since it provides 
a basic layer which makes utilizing immutability in various contexts 
possible. Thus, even though we might argue a couple of years about 
whether there should be a prim for turning immutability off or not, it 
shouldn't stop us from allowing the VM to trip over an object that has 
in fact been marked immutable. I do agree with that reasoning.

>     But in what applications? I suspect that the answer is "object
>     databases, object databases, and ... err ... object databases" ;-)
>
>     (not that I'm saying that object databases aren't useful or
>     important but I suspect this particular use of immutability is not
>     remotely as general in practice as people seem to imply - and if I'm
>     wrong, I'm looking forward to learning something new here)
>
>
> You've already discussed a broad use category in introducing concurrency
> above.  Another broad category is being able to pass by value in a
> distributed system.  Another is providing immutable literals.  None of
> these are to do with OODBs.

Well we're hypothesizing about some uses here. They haven't been 
implemented. What I've been wondering is how immutability in those 
systems has been *actually* used and in particular whether (m)any non-db 
apps or uses were amongst them.

> In VW there's a Modification Management framework that supports
> attaching modification behaviours to specific objects.  By default an
> attempt to modify an object is an error (except by the class builder).
> Managers attached to specific objects can handle modification errors
> in various ways depending on the application.  Above that you implement
> what you want, including GemStone's persistence framework.

Thanks. Any other known uses for this outside persistence (which is the 
"database" category) and immutable literals?

Cheers,
   - Andreas