decomposing immutibility

The ongoing discussion on immutibility would suggest that it
is a fundamental property that cannot be decomposed further; i.e.  it's atomic.
Since I am writing this post I obviously disagree.

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.
     (Locked has other meanings so if you want to invent a different
term go ahead.)
3)  An object is immutable if it has no instance varibles (i.e. 1)) or
if has instance variables
     and they are all immutable.

Conceptually this is a simple definition but there are practical
problems relating to cycles.
I won't try to clean up the definition here.  If you want to create a
cleaner definition go ahead.


My point is that if there is any kind of user control given given to programmers
with respect to the immutability property of objects in their programs
then similar
controls should be given to the locked property of objects.
If a user can make an object immutable then (s)he should be able to
make an object locked.  Further (obviously) I propose that the ability
to lock an object must be useful if making
an object immutable is useful.

So far I have argued that:
                       There is a command  makeImmutable(object)
                         ==> there must be a command  makeLocked(object).

I now argue that the converse is not necessarily true.
Perhaps there should be a command  makeImmutable or perhaps not and programmers
should make an object immutable by recursively making its instance
variables immutable.
I think which is better depends a lot on how these commands are
implemented in the
language and, more importantly, how difficult it is to do so.
I am not attempting to answer these questions here.

However, I claim that makeLocked is an easier command to support in a
language than
 makeImmutable  so it may be practical even if  makeImmutable is not.

Note that if the programmer only has the makeLocked(object) command
then s(he) can
introduce bugs in his/her program by believing s(he) has constructed
an immutable object
but hasn't because there's a bug somewhere.
This isn't all bad.  If an object  B  was meant to be immutable but
isn't because it has a
component  C  that should have been locked but wasn't then having to debug the
program to find out the location of  C  may be much easier than finding the bug
in a similar program in which locking is not used.

In summary,  if you want to add a  makeImmutable feature to your language then
get the makeLocked feature to work first.

Regards,

Ralph Boland

On 18.03.2010, at 18:41, Ralph Boland wrote:
... and it must be locked, in your definition. Otherwise you could store stuff into it so it's not immutable.

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. I think the "lock/beImmutable" primitive should fail if any slot contained something mutable.

- Bert -

On 18 March 2010 19:58, Bert Freudenberg <[hidden email]> wrote:
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.

> - Bert -
>

--
Best regards,
Igor Stasenko AKA sig.

On 18 March 2010 19:58, Bert Freudenberg <[hidden email]> wrote:
Yes, of course;  sloppiness on my part.

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

Yes.

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


Regards,

Ralph Boland