Closed jeizenga closed 5 years ago
This is a fine way to set up a high level interface to allow the compaction or reorganization of the graph in various ways that the implementer knows will help performance.
I still think we need to be able to maintain an order in the graph. There are a number of algorithms that I'd like to be able to run on many handle graph implementations, but won't be able to if I can't define a stable ordering that gets serialized and doesn't need to be re-derived every time the graph is loaded. My point is that this would be a good thing to promote in the handlegraph interface.
I'll make a new PR for this.
I believe I should have fixed the include order dependence (https://github.com/vgteam/libhandlegraph/issues/11) with the last commit.
I have an interface that that allows a semantically unspecified optimization step for the representation of a graph. I think this is general enough to handle the sorting methods we discussed earlier, as well as other potential optimizations we might want to make to the data structure.
I also thew in methods for
get_base
andget_subsequence
with default implementations. Those seem handy.