[squeak-dev] Re: immutibility
siguctua at gmail.com
Thu Apr 1 00:08:51 UTC 2010
On 1 April 2010 02:31, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 31.03.2010, at 20:45, Denis Kudriashov wrote:
> 2010/3/31 Bert Freudenberg <bert at freudenbergs.de>
>> 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.
> With your "become logic" reference to proxy (like proxy in magma and glorp)
> will never materialized if immutability used for object modification
> You are talking about a write barrier. I'm talking about immutability.
> As mentioned previously in this thread, these two are related, but not
> A write barrier might be more useful for current applications indeed. I
> simply wouldn't call that immutability.
> And it will break this frameworks (magma, glorp)
> Well if you make objects immutable you should be aware of what you are doing
> IMHO hard immutability would be a valid and consistent model. Whether it
> would actually be practical and useful in Squeak I'm not sure. There seems
> to be no compelling use case for it yet. OTOH, soft "almost-immutability"
> can be implemented in the image, so what would be the compelling reason to
> make this a VM feature, which almost certainly will come at a price?
Yep. IMO we should think more about models, which could help us to improve
a real, existing use cases (like Magma or GLORP).
IMO, an immutability as a separate model seems not very useful,
especially in 'hard' form, when it propagating through references.
So far, Squeak system is built without the need of immutability, and
it works well. And hence, it raising a logical question: how much we
really need an immutability as a core concept in object model?
In what areas it would simplify implementation and/or make it more robust?
> - Bert -
Igor Stasenko AKA sig.
More information about the Squeak-dev