search

JuliaCollections / LeftChildRightSiblingTrees.jl

Memory-efficient representation of a tree with arbitrary number of children/node
MIT License
16 stars 5 forks source link

Unintuitive AbstractTrees.children implementation #6

Open pfitzseb opened 4 years ago

pfitzseb commented 4 years ago

The current implementation simply returns the current Node, which of course works fine because it is iterable. It is also kind of confusing because children(node) === node looks strange. I briefly thought

children(n::Node) = (c for c in n)

would be nicer, but it turns out that doesn't work with AbstractTrees:

julia> AbstractTrees.print_tree(flamegraph())
FlameGraphs.NodeData(ip:0x0, 0x01, 1:299)
ERROR: MethodError: no method matching keys(::Base.Generator{Node{FlameGraphs.NodeData},var"#9#10"})
Closest candidates are:
  keys(::Core.SimpleVector) at essentials.jl:602
  keys(::Cmd) at process.jl:639
  keys(::Tuple) at tuple.jl:46
  ...
Stacktrace:
 [1] pairs(::Base.Generator{Node{FlameGraphs.NodeData},var"#9#10"}) at ./abstractdict.jl:132

An array comprehension is fine, of course, but also allocates an array.

So yeah, all in all I'm how actionable that complaint is, but the current behaviour was confusing for me at least.

timholy commented 4 years ago

I can understand that. The "raw" for c in parent (i.e., not using AbstractTrees) hopefully seems more intuitive?

The AbstractTrees interface was obviously an add-on, I mostly wanted the printing.