On Aug 13, 2009, at 4:27 PM, Krzysztof Kosiński wrote:


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.


OK. I think this is the crux of the matter.

What you've stated is not an "ends" at all. You've just stated one "means" in support of another "means".

===================
Q: *How* do you want to do that?
A: By iterating over references to an object.

Q: *How* are you going to iterate over them?
A: By using a nice triple-pointer list structure.
===================

So you've actually stated two "how" items and not any "why" items. The "how" items correspond to "means", and the "why" items correspond to "ends". Also, using the wording of my first example question there, you've not really stated what "that" is. 


===================
Q: *Why* do you want to iterate over references to an object?
A: Umm.... I dunno. Just some things.
===================

Often different structures are appropriate for solving different problems. I've personally seen where an array of pointers one walks and compares vastly outperforms "smarter" structures (I can go into that separately if you're interested). If you're trying to solve several different problems with one single structure then that's a red-flag.

I was thinking that the best thing to move forward would be to do a simple wiki page to list out specific use cases where this structure would be helpful. At the end, we might see that only one structure is needed. However, it might be that several end up more useful. I'm thinking of things like the DocumentSubset base class.