...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.
