In the current system, when a node is being destroyed, it removes
itself from the node tree (makes itself inaccessible to any parent)
and marks itself as `__LZdeleted`. Some methods protect against
trying to access a node that is in the process of being deleted by
checking this internal property. When this check is not made, it is
possible that a memory leak will be created by accessing the destroyed
node.
The proposed change is define that accessing a node that is in the
process of being deleted is an error.[1]
To facilitate detecting this error, we propose that when a node is
destroyed it will also remove itself from the node tree by setting the
`parent` and `immediateparent` attributes of any of its children
(which will be recursively destroyed as part of destroying the node),
to null, before those children are destroyed.[2]
Pro:
. It is already the case that a destroyed node will remove itself from
its parent and immediateparent subnode (and subview, if it is a view)
lists. If the node has an id, that id will be set to null. If the
node has a name, that name will be set to null in both its parent and
immediate parent nodes.
. There are no known cases in the LFC or components where a child node
needs to access it's parent when the parent is in the process of being
deleted.
. There are several bugs in the LFC where a child node will
(uselessly) update it's parent, even though the parent is in the
process of being deleted. These bugs will be fixed as part of
implementing this API change.
Con:
. It is possible that there is LZX code that could fail due to this
change because it assumes that the `parent` and `immediateparent`
attributes will always refer to a node.
Your comments solicited.
---
[1] By defining this behavior as 'an error', we mean that the behavior
is not supported and may cause your program to operate incorrectly.
The compiler and/or runtime will attempt to signal an error when the
erroneous behavior is detectable, but there may be cases where the
error cannot be detected.
[2] With the proposed change, attempting to access a destroyed node
through the `parent` or `immediateparent` attributes will be signaled
as an error, however, a child node could make a copy of either of
those references and erroneously access a destroyed parent in an
undetectable way.
