[squeak-dev] Re: immutibility

Igor Stasenko siguctua at gmail.com
Thu Mar 18 06:28:01 UTC 2010

On 18 March 2010 07:26, James Foster <Smalltalk at jgfoster.net> 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.
Immutability is not the only way how one can address the immutability
of literals.
Take a symbols, for instance: an implementation inherently maintains a
set of symbols and makes sure they are not mutable and unique.
This means, that we could do the same for any other kinds of literals:
arrays, strings, characters, and share them without the need of
introducing an immutable bit.

> 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.
do you mean, like this:

object beImmutable.
database commit: [ object ].
object beMutable.
object setFoo: bar.
object beImmutable.
database commit: [ object ].

the above is an example when object, recorded as an immutable one,
then mutated outside a DB transaction. So db can't capture the attempt
to modify it.
What GemStone doing to handle this?

Another thing, i think, is how to allow nesting:

object beImmutable.
  [ object setFoo: bar ]
   on: AttemptToModifyImmutable do: [:ex |  framework1 handleException: ex. ]
    on: AttemptToModifyImmutable do: [:ex | framework2 handleException: ex. ]

in this way, if framework1 were one who set immutable bit, it should
handle it and continue as normally.
but, if framework1 seen this object before as an immutable , then it
should pass the exception to outer layer, who may handle it -
But then it could be problematical to have changes made by framework2
be seen by framework1.

> 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.

I'd say that while immutability is helping to make databases more
fast, it actually has a much wider usability.
All that OODBs need is to track the objects which were modified during
Immutability is not the only way how to achieve that.

> James

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list