[squeak-dev] Re: decomposing immutibility

Ralph Boland rpboland at gmail.com
Thu Mar 18 22:57:26 UTC 2010

On 18 March 2010 19:58, Bert Freudenberg <bert at freudenbergs.de> wrote:
> > On 18.03.2010, at 18:41, Ralph Boland wrote:
> >>
> >> Allow me to make the following definitions:
> >>
> >> 1) Â Objects with no instance variable are immutable. (Is that a good
> >> definition?)
> >> 2) Â If an object's instances variables cannot be assigned to then the
> >> object is locked.
> >> 3) Â An object is immutable if it has no instance varibles (i.e. 1)) or
> >> if has instance variables
> >> Â  Â  and they are all immutable.
> >
> > ... and it must be locked, in your definition. Otherwise you could store stuff into it so it's not immutable.

Yes, of course;  sloppiness on my part.

> > > Also, it's not just instance variables, but indexable fields too.


> > Anyway, I can see no real value in this "decomposition". "Locking" is necessary for immutability, sure. But I'm not sure how useful "locking" would be if the "locked" inst vars had mutable values.

My opinion obviously is that "locking" is very useful if  immutability
is useful,
which is different from saying it is worth implementing.

> > I think the "lock/beImmutable" primitive should fail if any slot contained something mutable.

For "locking" this is pointless.  Requiring that "locked" objects
have only immutable slots makes "locked" objects immutable
and the two concepts indistinguishable.
I agree though that an immutable object must only have
slots that reference immutable objects (but see below).

> As i said, once you start automagically propagating immutability
> through all references, you have to deal with exceptions (like
> classes) and many others, like contexts, processes ,semaphores etc etc
> etc. As a result it will end up with terrifying complexity addon to VM
> logic.

> I'm really wonder, why all seems to forget that each object points to
> its class. Following this logic and a rule that all references of
> immutable object should also become immutable , then you should also
> make class to be immutable.
> Otherwise, if you don't, then i can modify an object's behavior , and
> in this way, it can't be defined as an immutable, because by changing
> its behavior i therefore , mutating its state to outsider's view,
> because it stops responding with same results to same messages.

> Best regards,
> Igor Stasenko AKA sig.

I agree that this is a problem.  However ,it is also a problem for
objects we now
consider immutable such as characters and integers.  So it comes down to
how we want to define immutability and, for those who agree that it is also
a good idea,  "locking".


Ralph Boland

More information about the Squeak-dev mailing list