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

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.