...but in fact, my troll answers actually not so far from real ones. When i was working with Goran on DeltaStreams (yes, capturing system changes), which using SystemEditor, i've been stuck with inability to properly track changes in traits, because SystemEditor was implemented by taking into account only classical ST-80 class model. Then i thought, okay, how else you can track changes ? The most general solution is do like OODB does: enter "transaction mode" upon final commit, see what objects are changed , without discrimination by traversing the graph. (as you can see it is not very far from having 2 image snapshots, and not very far from your example of code does which involves some serialization).. the problem is, of course, filtering e.g. what objects are considered important to track and what not.. But it is impossible to do it at object-level, without considering it's place in graph, e.g. some string object can be completely ignored (because it is string to write to Transcript "update finished") while other string, like source code of new method cannot be ignored and needs to be captured. Another problem is that such generic solution is very hard to represent in human-readable form e.g. method A changed to method B.. because it is graph of objects and unless you know exactly the role(s) of every object you cannot make any sense of how to present it to user. But then, assuming that even if you find solution to filtering & presenting the change, here again, what if filtering rules changed by themselves during system change? Which rules should filter the change: prior to change or after?. (and that's my second troll's answer).. -- Best regards, Igor Stasenko.

I am not really interested in conceptual ideas (with those I can come up anytime I want). I want an actual solution as an answer to my stackoverflow question with code that works ;) On 2013-05-01, at 03:31, Igor Stasenko <siguctua@gmail.com> wrote:

Ane of the idea is to use serialization, but with custom strategy. Since we're in living system, each object can know the answer to question whether it is important to capture it's changes or not. As well, as it can instruct serializer, what part(s) of its state needs to be serialized and which not.. This will give us the filtering rules out of the box.

But still it won't give us an automagic way to represent changes in human-readable form, e.g:

diff := someObject createTextualDiff: myPreviousSerializedVersion.

well, unless you serialize textual forms of both objects .e.g:

diff := someObject sufficientTextualForm createTextualDiff: myPreviousSerializedVersionSufficientTextualForm.

(the bad part of it that it is quite difficult to represent arbitrary graph with possible cycles in human-readable textual form ;)

-- Best regards, Igor Stasenko.