Jon A. Cruz wrote:
=================== Q: *Why* do you want to iterate over references to an object? A: Umm.... I dunno. Just some things. ===================
I don't understand you. I explicitly said why it's needed, at the very beginning. I'll repeat that list for you. 1 means the task would be simplified by "find hrefs to object", and 2 by "find hrefs in an object".
1. Generic clipboard code that does not require updates whenever a new type of SPObject that can refer to something is added (2). 2. Robust ID collision resolution (1). 3. Deleting objects that are referred to - currently deleting a gradient in the XML editor causes junk to be displayed and usually a crash (1). 4. Better vacuum defs (something like mark-and-sweep could be used instead of the current simple refcounting scheme) (2). 5. Editing a clipping path or mask that is applied to several objects - the outline should be shown over each item the mask is applied to (1). 6. Not having to redraw everything when a gradient, pattern, etc. is changed (1).
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.
There are only 2 problems to solve, and there are 2 separate but identical data structures that happen to have their data in the same object.
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.
See above. I may put this on the wiki if you want, but I'm not sure it would get more exposure than here.
Regards, Krzysztof