I thought I should start a new thread for this. My coworker is finding numerous UC-related bugs where things don't update properly. One problem is the WinForms ListBox as we have discussed before, but there are other, more mysterious problems. I would like
to debug them with some kind of visualization.
So I was proposing earlier a simple textual summary:
I'm not sure how to present this summary tree within a debugger. Currently
this article's approach won't work because Precedents are not serializable. But, moving on, assuming the list of persons has 3 items, an expanded version would be useful too:
* Person.FullName=Joe Johnson
* Person.FullName=Brock Braun
* Person.FullName=Patricia Trie
My first thought is that this expanded version could take advantage of the built-in debugger UI by replacing the default debugger view, as explained in
my article about visualizing IList<T>. The problem is, the user sometimes wants to see precedents (things that this Dependent depends on) and other times the user wants to see Dependents
(things that this Precedent depends on). To resolve this, you could simply offer a "Dependents" property in Precedent that returns a
tree of dependents, plus a "Precedents" property in Dependent that returns a tree of dependents and independents.
Come to think of it, both kinds of trees (summary and expanded) could be offered with properties. You could offer "DependentsSummary" and "PrecedentsSummary" properties that return summary trees instead of expanded trees.
Now the technical problem with the expanded version is that if the user uses Independent<T>, there is no link from the Independent to its value. Can you think of any solution? I've decided I like the idea of making Independent<T> a derived class
of NamedIndependent (and similarly for Dependent<T>) for this purpose, since it's cheaper memory-wise than the current implementation of Independent<T>... but of course it's a breaking change. Alternately, you could define new names for these derived-classes-with-T,
NamedIndependent<T> and NamedDependent<T>, to avoid breaking existing code. I know you said in the other thread,
"I don't think that inheritance is the appropriate relationship for Independent<T> or Dependent<T>. These classes live at a higher level of abstraction than the sentry classes. This would be considered implementation inheritance rather than
But implementation inheritance is the most straightforward solution to the visualization problem, and it works without needing to enable a special "debug" flag. I think I'll hack something together and send it to you. Sound good?