On 31 March 2010 19:25, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 31.03.2010, at 18:15, Igor Stasenko wrote:
>>
>> 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.
>
> Not at all. Of course you should not make an object immutable that you want to mutate later. That's the whole point really.
>

I'd say, that there is virtually no objects in system which you won't
want to mutate later (taking a considerably big time span).
Because otherwise, a system degenerates into a set of static state,
which you can't change , and the more static parts in system, the less
usefull it becomes from computational point of view.

>> 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.
>
> No, you just cannot use VM-level immutability for detecting this case.
>
> It would still be perfectly fine to put immutable objects into Magma. You just couldn't modify them. Again, that's the point of immutability.
>
> It'd also be fine to have a proxy for an immutable object. But when the proxied object is brought in, it will have to bring in all the objects it referenced, because these are immutable by definition, too.
>

I am assuming that you talking about immutability propagation here.
I.e. an immutable object can't have a references to mutable objects
itself.
Then , this means, that OODB having no means to keep only a partial
view of arbitrary objects graph in memory, because you have to bring
in all immutable objects at once, once only first become accessible,
no matter if it used or not (or will be used or not).
But such approach hits hard on OODB's efficiency, isnt?
And it is fun, because one of arguments for bringing in an
immutability is to serve for improving OODBs efficiency.

> - Bert -


-- 
Best regards,
Igor Stasenko AKA sig.