[squeak-dev] Re: immutibility
bert at freudenbergs.de
Tue Mar 30 11:09:01 UTC 2010
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"
- Bert -
More information about the Squeak-dev