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