You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, for the operations remove() and update(), there is the fast flag, which defers cleanup of empty subnodes. If I'm reading the docs correctly, the expectation is that remove/update would be called with the fast flag set to true for the entirety of one "batch" of cleanup, except the last one, where it would be set to false, and the cleanup of empty subnodes would happen all at once.
This is great if you know ahead of time how many removals that you're going to perform, but consider the case where inside of a loop, you conditionally remove an object from the tree. In that case, you don't know which removal will be the last one, so you can't easily determine which remove call should have the fast flag set to false.
This could be fixed if there was a cleanup() function, that you could run at the end of the loop.
The text was updated successfully, but these errors were encountered:
That's actually very helpful! I think including in the documentation specifically that it could be called after a fast flag to clean up subnodes would be helpful, and might be enough. As for renaming, I am partial to verbose and specific function names, something like cleanupSubnodes(), but I'm not a library dev, so feel free to take the suggestion with a grain of salt.
Currently, for the operations remove() and update(), there is the fast flag, which defers cleanup of empty subnodes. If I'm reading the docs correctly, the expectation is that remove/update would be called with the fast flag set to true for the entirety of one "batch" of cleanup, except the last one, where it would be set to false, and the cleanup of empty subnodes would happen all at once.
This is great if you know ahead of time how many removals that you're going to perform, but consider the case where inside of a loop, you conditionally remove an object from the tree. In that case, you don't know which removal will be the last one, so you can't easily determine which remove call should have the fast flag set to false.
This could be fixed if there was a cleanup() function, that you could run at the end of the loop.
The text was updated successfully, but these errors were encountered: