On 18 March 2010 17:23, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 18.03.2010, at 15:51, Colin Putney wrote:
>>
>>
>> On 2010-03-18, at 5:39 AM, Bert Freudenberg wrote:
>>
>>> HO there should be no way to reset the immutable flag. You can implement "soft" immutability in the image, but "hard" VM-level immutability needs to be permanent, no fiddling possible. Once set, the object stays immutable. Only a copy of an immutable object will be mutable again.
>>
>> This would be good for some use cases - literals, for example, but not so good for others. One of the common uses of "immutability" is not so much to *prevent* mutation, as to control it: databases, concurrency etc. Do you have another feature in mind for these cases, or some overriding interest in immutable immutability that you want to pursue?
>>
>> Colin
>
>
> Seems to me like two separate issues - one being informed of modifications, and one preventing modifications. Immutability to me means the latter. The former is more like a write barrier.
>
Right! And for OODBs first is sufficient.

> With true immutables you can start developing in a mixed object/functional style, which would allow interesting optimizations, e.g. for concurrency, memoization etc.
>
I don't sharing your optimism, based on immutability.
You can't run away from the fact that computing is the way of
transforming data from one form into another.
So, somewhere, either in language or at VM level, you have to mutate
the state of data, otherwise you can't do much.

> - Bert -
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.