On Thu, Mar 18, 2010 at 10:11 AM, Brent Pinkney <brent at zamail.co.za> wrote:

> Ahoy,
>
> I would like to contribute to this thread by explaining a problem that
> occurs often in telecommunications and logistics.
>
> It is common to have planning tools that allow the user to 'fork' the
> master view of the 'domain model' and make local changes to
> explore "what ifs". Alas. the domain model is a directed graph of many
> thousands of instances, born of hundreds of classes, so
> duplicating all of this is not feasible.
>
> I have always wanted an object mechanism to detect 'copy of write', so that
> I might slay this pesky problem. If I had "OCOW"
> (Object Copy on Write), I could let the happy users work on the master
> object graph and manage the small portion that was changed
> by an such user experimentation. Obviously, there would need to be a nice
> exceptions or dependencies to wrap all this.
>
>
> My question (I really do not know) then is: does immutability, as proposed
> in this thread, help ?
>

Yes.  For example take Alan Knight's GLORP framework which does
object-relaitonal mapping.  How does one maintain the set of changed objects
and the changes?  Mark the set of objects uploaded from the DB as immutable.
 As each is first written to, trap the exception, take a shallow copy of the
object and enter it into a dictionary mapping modified object to unmodified
copy.  At commit time the modified objects are the keys in the dictionary
and what slots have been modified can be found by comparing the unmodified
copy with the modified current object.  The use of immutability here is an
extremely beneficial optimization.  It avoids work, depending on what the
base implementation is, e.g.

- avoids having to compare the entire object graph with the state of the
database to discover differences
- avoids having to take a copy of the data set uploaded from the database
(makes copying lazy)

cheers
Eliot


> Brent
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100318/fe67a9ea/attachment.htm