[squeak-dev] Re: immutibility

Igor Stasenko siguctua at gmail.com
Wed Mar 31 16:15:12 UTC 2010

On 31 March 2010 18:24, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 31.03.2010, at 17:23, Andreas Raab wrote:
>> On 3/31/2010 8:13 AM, Bert Freudenberg wrote:
>>> Show me a single place that would break in a real-world use-case.
>>> In fact, #become: is rarely used in Squeak because of its inherent slowness caused by our direct-pointer object model. And those rare places I can think of would work just fine.
>> I think there is one, and only one, place where #become: is intrinsically required: Changing class shape.
> Thought about that. Should be fine.
Magma using a forwarding proxies to indicate a not-yet reified objects
in memory.

Suppose that you having multiple different objects, which referencing
such proxy.
Proxy is not reified before a first message sent to it and used as a
simple reference.
Nothing prevents you from having many other objects, which pointing to
that proxy without reifying a real object.
And now, think about that with introduction of immutability, some of
these objects is immutable. This means that it is now possible to have
an immutable object, which having a reference to forwarding proxy.
(even more than that, this is more than likely, because Magma will use
an immutability for own purposes, to track changes to objects which
belong to DB graph).
At some stage, your model sending a message to forwarding proxy, and
therefore magma needs to reify a real object
in memory and replace all references to proxy with it.
This is easy to implement by using a #becomeForward:, but if you
change the  #becomeForward: semantics to not replace the references in
immutable objects, you will efficiently break this scheme , and it
can't be used reliably anymore.

So, with such change, we have to invent a different way, how OODB
could reliably replace a forwarding proxy with real object, which is
read from remote storage.

> - Bert -

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list