conflating keys and nodes

I have just come to fully understand a problem that I was struggling with a bit when I wrote my 0.4 PR: current master on this package still conflates "keys" with "nodes".

To see what I mean by this, consider a Dict. Currently we define children(dict::AbstractDict) = pairs(dict) and some methods for Pair so that Pairs are by themselves nodes each with a single child (i.e. they are tree-equivalent to [p.second]. The problem with this is that p.first is supposed to play the role of an index, not a node. This matters because, for example, getdescendant (used to be called childindex but I changed it after a helpful suggestion by @jlumpe) cannot work with dictionaries, even though it has every reason to.

It's mostly clear to me now that the "right" thing to do is to deprecate the old behavior so that e.g. children(dict::AbstractDict) = values(dict) and delete all of the pair methods. However, this is making me a little nervous. My PR doesn't break very much in part because the tree structure of everything in Base is preserved. Making alterations to this tree structure is much more likely to be breaking. One place this would be manifest within AbstractTrees itself is print_tree, which would need to be altered.

In summary, the benefit of making this change would be consistent indexing behavior, with the cost of making what is probably a more significant change than any that were in my original PR. On the other hand, it probably won't break all that many packages.

Opinions on this?

Start by reading the issue's discussion of children, Pair, getdescendant, and print_tree in AbstractTrees.jl. Compare the proposed AbstractDict and Pair behavior with the existing tree structure and identify compatibility concerns. Done means the project has a decided scope and migration plan for separating keys from nodes.