Hello guys,

A SystemEditor is the only tool , currently existing, which allows us
to perform an atomic updates.
However, its having own shortages.
A SystemEditor mimics the Behavior/ClassDescription/Class protocol,
so any change you going to make to system is recorded , but not
applied immediately.

This is good, but at same time, this is the main source of shortage,
because once you may want to change the Behavior protocol(s), or
extend it (see Traits), you gonna to change a SystemEditor as well to
mimic new behavior and new state, otherwise it wont work as expected.
Needless to say that, keeping two different parts of system
synchronized doubling the amount of work, as well as makes it brittle
and highly error prone.

So, i asking the question, is it possible to implement a framework,
which would be able to:
 a) capture changes to any object(s) of interest.
 b) serialize/deserialize captured changes (to file out/in)
 c) apply changes atomically

One of the ways, i'm thinking of, is to use a 'capture-by-intent'
i.e., whenever you think that a state change should be recorded, you
using a special protocol for recording that change. And framework,
which lies somewhere in system takes responsibility for recording it,
while in code you don't have to care much about details, and it should
look pretty much as usual, like:

Foo>>bar: anObject
   bar := anObject

Now, if we rewrite it like this:

Foo>>bar: anObject
   self captureIvarChange: #bar action: [ bar := anObject ].

we now should be able to capture the change of 'bar' instance variable
in receiver.
A framework could choose to:
 - [very][deep]copy the original value of 'bar'
 - apply the action block
- (optionally) compare the new value with old one and see what changed
based on this analysis , produce a delta, which can be serialized and
then reconstructed in different image/environment.

Also, by making sure, that there is no other assignments to 'bar' ivar
in our code, except in #bar: accessor, we 100% guarantee that any
change to our state
can be captured.
Same scheme, of course, can be used for capturing changes to
collections and variable size receiver's.

The intent is, that we should put such hooks directly in the places
where actual changes is made and at such places, which we consider
worth to capture, so, the code which capturing the change will live
together with code which actually does the change, but not in separate
layer like SystemEditor.

Then we can be sure, that no matter what permutations we making with
core system classes & state they holding, we could be able to track
all changes without need to synchronize it with some 'tracking code'
which lies in separate place.

Also, potentially, such framework should work in three different ways:
- recording changes while someone applying them (same as DeltaStreams does)
- recording changes, but not applying them (same as SystemEditor does)
- replaying changes

-- 
Best regards,
Igor Stasenko AKA sig.