Closed mgedmin closed 7 years ago
See PR #68 for my attempt at a solution to this (and to any situation where you try to call move_node()
between a parent/child; this caused them to simply disappear into thin air)
That still leaves a bug when you try to move a node under one of its grandchildren. You need to check if the node you're moving appears anywhere in the destination's ancestor list, and disallow that move.
I think the more glaring problem is that move_node()'s intentions seem really broad, and we're having to one by one disable what it (maybe?) should do. Because, for example, how do we know whether the original author would be okay with disabling movement to the destination if it is a grandchild? This is something that had to be said beforehand.
I think this function can use some extension: add an optional mode
parameter which defaults to a 'smart' move strategy, and some other modes like force
or safe
which will have well pre-defined strategies in case the user wants them.
Either that, or list out case by case what is permitted by this function and what isn't. If too little is actually permitted, the function should be deprecated and a different set of functions to handle the few permitted cases should be added.
I'll wait on the repository maintainer's opinion on this.
@mgedmin thanks for your issuing and @UmanShahzad 's solution, honestly partially. As you said, we will lose generality if merely checking parent/children or grandchildren. A straightforward and generic solution may be making a loop validation before taking actions. Otherwise, a LoopException raised.
@caesar0301 I will see if I can do that soon, and will update the PR
@caesar0301 Please see PR #68 now, thank you!
Example: