xmltree: offer a way to iterate over a whole tree (similar to items/mitems, but recursive)

[sschwarzer]

Summary

I'd like a way to iterate over all child nodes of an XmlNode (non-mutating and mutating).

Note that this differs from items and mitems in that it doesn't only iterate over the immediate children of a node.

The proposed feature differs from findAll in that it finds all nodes, not only those with a given tag. Also, unlike findAll, there should be a way to mutate a tree while iterating over it.

Description

At the moment there's no easy way to recurse over all, i. e. also nested nodes (apart from copying the recursion from findAll's source code or writing it yourself).

My application is that I want to iterate recursively over a node (tree) to delete certain nodes and delete certain attributes.

Alternatives

I don't know a way apart from writing code that combines code from items/mitems with the recursion of findAll.

See also the comparison with items and mitems in the "Description" section above.

Additional Information

• We had a discussion on this on IRC yesterday, but this didn't cover the mutating case.

• @disruptek suggested an API that could/would be applied to different tree-like structures in the standard library.

• The documentation for items and mitems currently isn't clear about whether they iterate only over the immediate children of a node (which is the case) or over all children recursively.

• There's an issue xmltree: Clear a node, not only its children #11729 which is remotely related (also since the discussion moves to a new, although not concrete, node finding API). That issue covers different functionality, but it may or may not make sense to consider that issue when designing the API for this one.

[sschwarzer]

The documentation for items and mitems currently isn't clear about whether they iterate only over the immediate children of a node (which is the case) or over all children recursively.

I entered a pull request #11930 for the xmltree documentation change. Feel free to edit the patch or the commit message as needed.

[disruptek]

I managed a pretty simple lazy tree iterator. Ideally, it gets low and high added to xmltree, because they should reflect values that are currently private. 🙁 For now, you can make it work by implementing XmlNode.high with len.

Returning to the topic, is there any reason not to accept a PR for low and high on collections that accept the [] operator? I notice that json lacks these as well.