The Problem
You libraries proofs really useful to create a dendrogram, but at the moment it is not really possible iterate through the tree structure and colleced the leaf names (e.g. ids) by their distance: The dendogram data structure itself doesn't know the names (the labels are only node numbers), and when processed with the Tree()
method, I only receive a string
(Newick) representation of the tree with names/ids assigned. I would have to parse this string
representation, which is error-prone and not really desirable performance-wise.
In more general terms, the use of the generate Tree is quite limited at the moment.
My Proposal
Let the Tree()
method return a typed Tree
(which doesn not just hold some strings but nodes and leafs (with distance as well as names/ids). The returned Tree
type could provide a method String()
for the Newick representation, as well as an Order()
method and maybe some others.
The advantage of this approach is not limited to my special use case: in general a real tree structure allows you (and all users of the library basically) to provide more and more methods on that very Tree
, not just String()
and Order()
, and could be even abstracted into a visitor pattern (which might become more relevant once Generics finally make it onto Go, which should happen in the nearer future). With the visitor pattern, you'ld unlock huge flexibility without the need add new methods.
If I find time I could try to provide a PR myself, but I'ld like to hear your opinion about that first.