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