On 31 March 2010 16:07, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 31.03.2010, at 15:03, Igor Stasenko wrote:
>>
>> On 30 March 2010 14:09, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>> On 30.03.2010, at 11:45, Bryce Kampjes wrote:
>>>>
>>>> On Thu, 2010-03-18 at 16:40 +0100, Bert Freudenberg wrote:
>>>>> On 18.03.2010, at 16:30, Ralph Johnson wrote:
>>>>>>
>>>>>> On 3/18/10, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>>>
>>>>>>> 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've developed in a mixed object/functional style for years, and I
>>>>>> think a lot of other people do, too.   You don't need language support
>>>>>> for this, though I expect it would be helpful.  It makes concurrency
>>>>>> and distributed programming easier, and is important when you are
>>>>>> dealing with databases.  Eric Evans calls this "Value Object" in his
>>>>>> book "Domain Driven Design".
>>>>>>
>>>>>> -Ralph Johnson
>>>>>
>>>>> Right, the style is possible without VM support in your own subsystem. But being able to *guarantee* immutability would allow to generalize this beyond your own special-purpose code. And possibly it would enable further VM-level optimizations.
>>>>
>>>> Even perfectly VM enforced immutability isn't enough to allow
>>>> optimisation if you still allow become:. It's always possible to swap
>>>> out the immutable object with a different one via become:.
>>>
>>> It's fine to swap immutable objects, unless the object holding the reference is itself unmutable. No instance variable of an immutable object can be stored into, not even by become:.  Obviously, become: would have to honor the immutability flag:. For references inside immutable objects, become: becomes a forward-become (or a no-op if both were immutable):
>>>
>>> a := Array with: A new.
>>> b := Array with: B new beImmutable.
>>> c := (Array with: C new) beImmutable.
>>> a first become: b first. "a points to the immutable B instance, b to the A instance".
>>> a first become: c first. "both a and c now point to the immutable C instance"
>>>
>>
>> one of the problem with #become:/becomeForward: that it should swap
>> all of existing references atomically.
>> Now imagine that while walking the heap, it replaced a 50% of
>> references to given object, and then discoreved that it
>> needs to swap a reference held by immutable object.
>> Now, what you suppose to do? Revert all changes and fail primitive?
>> Ignore this object (do not alter it references) and continue?
>> Or, before doing the real swapping, scan the heap and check all object
>> to make sure that none of them are immutable and so, #become will work
>> ok?
>
> Just ignore all writes into immutable objects (that is, in the become code, do not insert a forwarding block), otherwise proceed as usual.
>
But such semantics is no longer can be treated as #become (or #becomeForward),
because you leaving a references to old object instead of uniformly
replacing them with swapped one.

> - Bert -
>

-- 
Best regards,
Igor Stasenko AKA sig.