I did find a bug though with the Depth first traversal.

i.TraverseDepthFirstWithParent(i, valueselect, childselect)

should be

i.TraverseDepthFirstWithParent(t, valueselect, childselect)

Wrong parent! Maybe that caused some confusion, sorry if it did!

/me shakes his head to clear his thinking…

The easiest way to see what I mean is to simply use the identity function for the valueselector.

In most trees, the child node will have no reference to it’s parent node. The with parent methods are simply to gather this information during the enumeration.

I am not sure how you mean the semantics change mid-method. Had a quick look, but could not see anything wrong. Will have another look tomorrow.

Because these two different definitions seem to be used interchangably: in TraverseBreadthFirstWithParent() you have:

yield return new KeyValuePair(valueselect(e), t);

in which the parent is the node that the value came from, and later in the same method you have:

yield return new KeyValuePair(valueselect(c), e);

in which the parent is the parent of the node that the value comes from.

This seems quite inconsistent, and makes it difficult to reasonably document the functionality of these methods (how is the user supposed to know which set of semantics is in play, especially when it changes mid-method?).

It makes me think that the *WithParent() methods should really be *WithInfo() methods, and return and IEnumerable, with:

class TreeNodeTraversalInfo
{
public readonly TResult Value;
public readonly TSource Node;
public readonly TSource[] Path;
}

but maintaining Path is something that I’m not sure about — it may be too much overhead, as it’ll be a required array allocation for each returned node (yech).

Though Path could instead be an IList, which would allow some sharing of the underlying array (but would still require a unique instance per item returned).

http://anonsvn.mono-project.com/viewvc/trunk/rocks/Mono.Rocks/Object.cs?view=markup

The only major changes were using a KeyValuePair instead of a KeyValuePair, parameter validation, and the introduction of Create*Iterator() methods (so that the `yield’ statements are separate from the parameter validation logic, otherwise parameter validation would have delayed execution semantics).

I guess best will be to make a NodePair struct with Value and Parent properties.

Feel free to make any changes.