[Laszlo-user] API change proposal: <node>/destroy behavior when destroying child nodes recursively

[P T Withington]

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.