Proposal for modified interface to do reverse iteration on paths

[jeizenga]

This is my proposal to address the concerns I noted in the discussion on https://github.com/vgteam/libhandlegraph/pull/13. Changes include:

• Renamed methods to use a terminology to refer to the endpoints of paths that I think is more internally consistent as well as more consistent with the STL (path_begin / path_end / path_rbegin / path_rend)
• Reverted the stock implementation of for_each_step_in_path. I'm willing to be convinced otherwise, but it really looked to me that the new edits were broken and would result in an infinite loop on circular paths.
• Updated the documentation to be (in my estimation) more unambiguous and specific.

I think the confusion we're having might be partly due to differences of opinion on what the iteration should be doing on circular paths. I wrote it so that you could in principle loop around a circular path forever. That is, the end of the path will loop around to the beginning when you call get_next_step. Do we all agree that this is the correct behavior?

[ekg]

I think the confusion we're having might be partly due to differences of opinion on what the iteration should be doing on circular paths. I wrote it so that you could in principle loop around a circular path forever. That is, the end of the path will loop around to the beginning when you call get_next_step. Do we all agree that this is the correct behavior?

I think it makes sense to loop forever with get_next_step on a circular path. But the path does have an actual beginning and end in its storage. This issue pushes us out of the semantics that make the STL so clean and nice.

I think I've come around to your way of thinking about this. I do want us to have something akin to path_front and path_back (which I had hacked path_begin and path_end into).

Maybe we can discuss this briefly on the call.

[jeizenga]

Okay, new update. Since I think we didn't like path_rbegin and path_rend, I changed them to path_back and path_front_end. I still don't love it, but I think I like it better than anything else so far. I also switched back to Erik's for_each_step_in_path, which I no longer think was broken.

While I was in there I also reorganized handle.hpp a bit to make things easier to find, and I renamed node_size to get_node_count, which more closely matches the language used in the path handle interface.