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?


> - Bert -
>

-- 
Best regards,
Igor Stasenko AKA sig.