-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide consuming movement methods so that NodeMut can act as a cursor. #33
Conversation
This is perfect. As I said, |
This is an excellent approach! Huge thanks @adamreichold, your contributions are invaluable! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent work! I appreciate the symmetry you've achieved. Additionally, I think the axis
and into_axis
functions enhance the code's readability.
Do you think that we could also take advantage of this to implement mutable and owned iterators for NodeMut? |
You mean something like impl<'a, T: 'a> NodeMut<'a, T> {
pub fn children(&self) -> ChildrenMut<'a, T>;
} which yields distinct instances of If so, then I don't think these methods help to implement this safely as while these methods can "advance" a This would only work with a lending iterator which yields a |
Realising how important it is to hold on to an existing mutable node reference, I added a second commit which extends the signature of these methods to fn into_axis<F>(mut self, f: F) -> Result<Self, Self>; return the current reference as |
This is true. |
Note that this would not be an iterator though, i.e. not an implementation of the
node = match node.into_next_sibling() {
Ok(node) => node,
Err(node) => node,
}; We could of course provide methods like pub fn to_next_sibling(&mut self) -> Result<(), ()>; which modify Would you prefer that? If so, just the |
This is a good idea which would immensely benefit from better documentation |
Agreed |
Will amend the documentation if we decide to stick to the |
Personally I would love to have both implementations. I'm just a bit concerned about code duplication. I think that, to avoid overcomplicating the When chosing, I prefer the alternative which hides the least state possible. |
If you all agree, I approve to merge this PR into master |
While trying, I also realized that the implement of |
…navigation is not possible.
I amended the docs as requested, so from my point of view, this is good to go. |
Totally agree. Let's finish documenting this code and merge. I just want to point out that I have created a readme in which I try to summarize the design choises made in creating |
@adamreichold rebase your branch on top of master |
I have rechecked, everything LGTM |
Thanks. I would be glad if we could make a point release (for the |
Releasing 0.8.0 ASAP |
Still a draft because I added only theAdded the missing methods after trying out a bit deduplication of internals.into_next_sibling
method instead of handling all axes until we agreed that this is a helpful approach.