[squeak-dev] Re: immutibility

Bert Freudenberg bert at freudenbergs.de
Thu Mar 18 12:39:38 UTC 2010

On 18.03.2010, at 06:26, James Foster wrote:
> On Mar 17, 2010, at 8:45 PM, Igor Stasenko wrote:
>> On 18 March 2010 03:35, Chris Muller <asqueaker at gmail.com> wrote:
>>> This is where I start to get confused.  If "immutable" is a global
>>> attribute of each object, wouldn't there need to tend to need to be
>>> only one universal user of the bit at a time?  Otherwise, the database
>>> might be setting the bit on an object for it's purposes, but for which
>>> the [your other favorite framework] in having its own purposes for the
>>> bit, might not want it set at that time...?
>> Good point. Really, what you would do, if you having two frameworks,
>> sharing same object,
>> and both want to use (set/reset) immutable bit for own purposes?
>> This creates a conflict.
> Yes it does, so you need to make a decision about which of the two frameworks you will use, or you need to look at using them in such a way that they don't interfere with each other. Consider the two most likely candidates for use of immutability (in my experience): compiler and database proxy. 
> - With immutability, the compiler can share literals (strings, arrays, etc).
> - With immutability, a database framework can recognize modifications to objects copied from a remote system.
> For the most part, these two uses will not conflict. The potential conflict would be where a compiler literal is passed to the database framework and written to a remote store. By default (say) the database framework would mark the object immutable and if a modification was attempted it would log it as 'dirty' (needing to be written in the next commit) and then change it to be mutable. This would corrupt the compiler usage.
> The solution is to have the database framework notice on its first write that the object is immutable and keep it in its cache with a 'immutable' flag so that it would not accept an attempt to modify it.
> The general rule is that one can only make mutable something that one has earlier made immutable. With that, the risk of conflicts is much reduced.
> In any case, the potential for a conflict is not a reason to deny the feature. One simply has to use it carefully and with knowledge of what the frameworks expect.
> James

IMHO there should be no way to reset the immutable flag. You can implement "soft" immutability in the image, but "hard" VM-level immutability needs to be permanent, no fiddling possible. Once set, the object stays immutable. Only a copy of an immutable object will be mutable again.

- Bert -

More information about the Squeak-dev mailing list