Thanks - see the next post i made, where I introduce Lambda Expressions to make debugging more intuitive.

I took the technique for storing serialized snapshots from Juval Lowy’s Transactional, where he used serialisation to store the state in case of rollback. It will create an overhead, but as you will have noticed, the parts that take the snapshots are marked with Conditional(”DEBUG”), so that they will not encumber the system in production. The point of this is to augment debugging facilities. After all, finding the constraint violation in production using DBC is not going to help (tho it would be nice) since the program is still broken.

I see your point about the nesting of scopes - it was kind of unnecessary really. A simple static class would have sufficed.

Cheers

Andrew

I have to admit I’m a little uncomfortable with the way you’ve implemented preservation of the “before” state of the object….

I realize that in order to support the “before” functionality, you need to be able to copy the object’s properties… But if they are complex objects, it seems like storing off a copy of every property regardless whether they are actually referenced in the constraints could sometimes have prohibitive performance impacts, even for debug/test mode.

Then there’s the text overhead of XML in memory. Though without attributes and all that jazz, it might not be so bad.

I’m also not sure I see the value in keeping a static stack of scopes. This might be useful with recursion I suppose. But beyond that, it seems like it would imply a very tight coupling between different methods.

I know the contract should be thought of as being one layer above the algorithm/code itself. But if constraints in a method are dependent on what’s going on in the calling method, that really implies to me that the methods are way too tightly coupled.