On 18 March 2010 17:55, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 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 ;)
>
It is good to use a universal approach in modelling the universe.
And as to me, 'everything is an object' is more universal than
'everything is a function' ;)

> - Bert -
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.