- no memory allocations when adding a reference = better performance.
That may or may not be true. However the bottom line for performance items is to get solid metrics before and after.
ObjectRefBase acts as an intrusive list. Look here: http://www.boost.org/doc/libs/1_39_0/doc/html/intrusive/performance.html In particular look at the back insertion / deletion benchmark (what we're doing when adding or replacing a reference) - it shows at least 3x better performance for an intrusive list of small objects.
Some of the issues are nice. However the overall impression I get here is of a system that breaks encapsulation.
In what way? It doesn't try to refer to implementation details of any particular SPObject. It just stores some of the data that's passed to its methods in some place. If this solution breaks encapsulation, then virtual functions do as well (we could have a virtual function that returns a list of references but that would result in a LOT of error prone boilerplate, which this solution avoids completely).
The signals part also raises some major issues. At the moment we have two trees of data (SPObject *and* xml repr) that tend to get out of sync.
This issue is not related to the problem I'm trying to solve at all...
Also it is good that you've seen the id's as a problem. The code early on needed to put an id attribute on every single XML element. We have cleaned up much in the code and should be able to further attack things on that point. Why is this pertinent? Well, if one has id's on everything then then ID changing and clash prevention is a huge problem. However, if instead of having thousands of IDs in a document, one only has a dozen then the problem is a completely different one, with different parameters, scaling needs, etc.
The fact that you don't have IDs on every document doesn't change anything: It's sufficient to open the same document twice, modify one of them, and paste from one to the other to get an ID conflict. So we still need those capabilities.
I guess what I'm trying to point out is that instead of focusing on an optimized list structure,
The list structure is only a means to an end, which I outlined at the beginning: to be able to iterate over references to an object, and to iterate over references in an object. Those very generic capabilities will make a lot of code simpler, and they're not really related to the structure of the document. The concept of reference between objects will not go away no matter how we change the SP tree.
Regards, Krzysztof