On 18.03.2010, at 16:45, Igor Stasenko wrote:
> 
> 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.

Free advice of the day: don't ever get near a convention of functional programmers ;)

- Bert -