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 when e.g. iterating over children(node) you can mutate the tree while the iteration is happening. This will likely lead to unexpected behavior (note: changing or updating the AbstractElement is fine).
We should minimally document that you should not do that. However, I wonder if there is something else we could do to make sure that you don't get bad behavior. A few options:
Collect Nodes into an array when iterator is constructed and then naively iterate over that array instead. If some of them get unlinked etc., then that won't affect the iteration per se. However, this will mean allocating a potentially big array (especially in the whole-tree case).. we could have an keyword argument for iterator functions to allow for unsafe, but efficient iteration (e.g. children(node, unsafe=true)?
Make the tree immutable during iterators. This would mean attaching some global metadata to each node (e.g. something as simple as a Ref{Bool}).
The text was updated successfully, but these errors were encountered:
Make the tree immutable during iterators. This would mean attaching some global metadata to each node (e.g. something as simple as a Ref{Bool}).
Alternatively, if we do it carefully, we could wrap all Node instances that are returned in the tree iterators in some other type, e.g.
struct ImmutableNode{T}
node::Node{T}end
that does not allow mutating the fields, and all the mutating functions would fail on this node. getproperty would be forwarded to .node, but would still have to wrap anything that returns a Node in another instance of ImmutableNode.
Currently when e.g. iterating over
children(node)
you can mutate the tree while the iteration is happening. This will likely lead to unexpected behavior (note: changing or updating theAbstractElement
is fine).We should minimally document that you should not do that. However, I wonder if there is something else we could do to make sure that you don't get bad behavior. A few options:
Collect
Node
s into an array when iterator is constructed and then naively iterate over that array instead. If some of them get unlinked etc., then that won't affect the iteration per se. However, this will mean allocating a potentially big array (especially in the whole-tree case).. we could have an keyword argument for iterator functions to allow for unsafe, but efficient iteration (e.g.children(node, unsafe=true)
?Make the tree immutable during iterators. This would mean attaching some global metadata to each node (e.g. something as simple as a
Ref{Bool}
).The text was updated successfully, but these errors were encountered: