On 2009-12-24, at 9:42 AM, Igor Stasenko wrote:

> 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

Hi Igor,

I agree with your assessment of SystemEditor - the design is inherently fragile, because it relies on one set of objects closely mimicking the behaviour another set of objects, but with a completely different implementation. It's definitely error-prone and the parts of SystemEditor that mimic the class-modification protocol are the ugliest. 

However, I think that a generalized framework for capturing state changes and applying them later is a Very Hard Problem. It might be possible if you implemented a new Smalltalk with transactional semantics like Gemstone: commit and abort operations, and a third operation to abort-but-create-a-change-set. Encoding the change set in such away that it was reasonably independent of the starting state and could be applied to a *different* starting state is an exercise I leave to the reader, but one can imagine that being free to play with the semantics of the programming language could make it feasible. 

I think that trying to implement this against an existing system with lots of legacy code would be impossible. Every so often somebody runs up against some limitation of Monticello and wonders why we didn't just implement a generalized object versioning system. This is another framing of the same problem. I don't have the math or comp sci chops to prove it, but I bet it's one of those nature-of-computing issues. I suspect that solving this problem would require solving the halting problem, or proving that np=p or some similarly stupendous theoretical achievement. 

The approach we took with Monticello and SystemEditor was to cheat by limiting the domain to a certain set of objects with well-understood semantics, ie, the Smalltalk meta-objects: Classes, methods etc. There might be a better way to implement SystemEditor, make different engineering tradeoffs etc. I don't think there's a way to make it robust in the face of changes to the semantics of Smalltalk language, like Traits.

Colin