2008/7/30 Janko Mivšek <janko.mivsek at eranova.si>:
> Dear Squeakers,
>
> A bit explanation of immutability will help you understand what it is good
> for and why it is good to be introduced in Squeak.
>
>   1. immutable object = read only object. That means you can read it but not
> write/change its state. Where is this good for?
>
>   2. Literals should be immutable by default. Like 'this is a literal
> string'. Most of debate so far were about such immutable objects.
>
>   3. But the immutability become really powerful for persistence support.
> That is, as transparent persistence as possible, without any special
> commands for storing objects into a database. How can this be achieved with
> immutability?
>
>   4. With a clever trick: object to be saved into a database (persistent
> object) is declared as immutable. When we try to change it, an exception
> occurs. In exception handler we temporary declare object as read/write,
> allow the change then declare object back to immutable. We also put that
> object into a set of changed or so called 'dirty' objects. All we need to do
> now is to save them to a database during a commit.
>
>   5. That's how the Gemstone persistency is implemented completely
> transparently on VisualWorks, which supports immutability for a while.
>
>   6. Consider how transparent can become Magma with immutability in Squeak!
>
>   7. Consider many other uses when you need to detect object change. We can
> for instance implement logging of changes into a file and reverting in case
> of image crash, just as we are doing now with the code changes.
>
> In any case introduction of immutability opens us many new opportunities,
> which outnumber the small performance penalty it introduces.
>
>

As i said before, an immutability should be provided through behavior
(by disabling/removing methods which can mutate an object) not by
state (hidden mutability flag).
All is good, when you sitting in single process doing everything in
old-fashioned single-headed realm of computation.
But if you try to use immutability in parallel tasks , you'll find
things very-very odd.
Suppose you having two processes A and B, running in parallel.

Process A works with OODB and runs inside a transaction which
temporary sets an immutable bit of interesting object and catching
exceptions to track its changes.
But Process B doesn't know nothing about any transaction and plays
with object in own ways, assuming that it is mutable.
Now, when you try to modify an object state in process B, an exception
will be thrown, but since there is no handler (which is set up only
for Process A) - process will simply fall into debugger.
So, you failed to handle the exception, moreover , you trashed the
working code to error.

Now compare with replacing a class of object:
(consider a pseudo-code)
barrier := WriteBarrier session: myOODBSession.
barrier putOn: someObject. (which replacing an object's class with
itself and stores original class in its inst var).

Now even if you try mutate object in another process - there is no
chance that it will be not handled.


-- 
Best regards,
Igor Stasenko AKA sig.