|Well, as an example, when you step through the list you might have something like:|
tree---A.xml > B.xml, C.xml
||\----B.xml > C.xml, D.xml
|\-----C.xml > D.xml
Traversal would work like this:
1. Look at A. A requires B, so is B in the list?
3. Look at B. B requires C, so is C in the list?
5. Look at C. C requires D, so is D in the list?
6. D is in the list, so C is OK, remove D from all parts of the tree.
7. Go back to C, which has no more dependencies, so remove it from the tree.
8. Go back to B, which has no dependencies (removed when checking C and D), so remove it from the tree.
9. Go back to A, which now also has no extant dependencies. Remove A from the tree.
10. No nodes are left, so everything succeeded.
Obviously, and step in the traversal where you go and look at the list of loaded plugins and "oops!" a dependency is missing, is going to fail every one of them that requires it. In this example, there are a lot of nested dependencies, but even if it was A>B>C>D>E, then it doesn't matter if you start with A and hop through to E, then back track, or you start with D. Load E, fixes D, which removes "both" from the chain under A, leaving you with A>B>C. Then you just finish off the next item in the list of plugins, and their dependencies. The more you check to see if they line up, the fewer other chains need to be checked.
Now, you are right, there "is" a problem with looped dependencies. And, I am not sure how you do that.. Best I could say is that you maybe mark the dependency some way, in both. If you had:
A requires B and D.
B requires A and C.
Then you can't know if B is valid for A, until D and C are checked. So, you check C, its OK, which marks B as "codependent", so once D is checked, A becomes valid, and so does B, and both can be removed.. But, that is a simple case.. there has got to be some way to handle that, but I am a bit stumped. It would be easier to deny such interdependence or deny "load all, then sort it out". lol