-
Notifications
You must be signed in to change notification settings - Fork 98
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
Expand remove
API
#513
Comments
We could also pass in an enum like I think we should have |
I think we might also want a |
What problem does this solve or what need does it fill?
This issue continues discussion from #511. In that PR, remove behavior sets the children's parents to
None
as a conservative fix to #510. This is not the only way to manage a deleted node's children, however.What solution would you like?
I would suggest an API such as the following:
remove_reparenting
- Remove node and reparent children to grandparentremove_orphaning
- Remove node and orphan childrenremove_cascading
- Remove node and all its children recursivelyAnd then we can select one of these to stand for the default
remove
. One suggestion here was:I would advise against this as default behavior from the perspective of avoiding implicitly destructive defaults. In practice, the library consumer will end up with potentially a ton of stale
NodeId
references, which may be better as opt-in rather than opt-out.That being said, the recursive remove is probably the most common use case. And orphaning by default can lead to potential memory leaks as orphaned trees continue to exist unnecessarily in memory.
Once a specific API is agreed upon, I am happy to draft a PR. (I'll write test cases/docs this time :p)
What alternative(s) have you considered?
We merged a simple fix in #511
If it would be preferable we can use more verbose names like
remove_and_orphan_children
. Or less verbose likeremove_orphan
,remove_cascade
,remove_reparent
. No preference there personally.Additional context
@nicoburns pointed out:
So maybe we don't want a
remove_reparenting
endpoint just yet?The text was updated successfully, but these errors were encountered: