Result of children required to be Indexable, not just Iterable

[krcools]

I tried to model my own tree upon the concepts introduced in this package by simply defining children as a function that returns an iterator over the children of a given node. This immediately enabled print_tree. I was not able to use e.g. 'Leaves'. The problem seems to be that the children collection should be indexable as opposed to be merely iterable. Also the supplied example demonstrating directory traversal suffers from this:

include("examples/fstree.jl")
ns = collect(Leaves(Directory(pwd())))

MethodError: no method matching getindex(::DirectoryListing, ::Int64)
in collect at base\array.jl:431
in _collect at base\array.jl:442
in start at AbstractTrees\src\AbstractTrees.jl:494 
in firststate at AbstractTrees\src\AbstractTrees.jl:398
in isempty at base\essentials.jl:358 
in childstates at AbstractTrees\src\implicitstacks.jl:41
in getnode at AbstractTrees\src\implicitstacks.jl:2

I was able to fix this by defining

Base.getindex(dl::DirectoryListing, i::Int) = dl.names[i]
AbstractTrees.nextind(dl::DirectoryListing, i::Int) = i+1

This fix, however is does not work as in my implementation there is no easy way to predict the location of the i-th sibling in the underlying buffer.

What are the ambitions of this package? Does it aspire to define the vocabulary and interface for all tree implementations (as AbstractArrays tries to accomplish for Indexables)? Or would you advise to start a separate package. I would like to avoid proliferation of the package ecosystem with similar but different concepts if possible...

Is this framework written for convenience or is it also suitable for high performance large scale trees? If all nodes are of the same type, will the framework take advantage of this?

[Keno]

Hi there, sorry for not seeing this earlier. This package has mostly been a way for me to collect various tree-related code I needed for other code, but I would certainly hope that it will be more widely useful. I spent some time a while back specifying the exact requirements for trees, but never got around to finishing it. With respect to the indexability requirement, we can likely drop that, though we'd have to add an extra trait and maybe add buffering in some of the iterators.