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

[André Bargull]

[Let's provoke some annoyance  :-P ]
Oh wait, you just said nothing in the LFC depends on the current way 
things work. I really believed in you, so I applied your change and now 
my super, next-gen OpenLaszlo application [1] doesn't work anymore in 
the new swf9 runtime. Somehow some LFC code [2] assumes it will always 
get a valid reference to a node when accessing the immediateparent 
property. And also my other best-selling application [3] gives me 
runtime errors in swf9 [4]. Can you explain? ;-)

[1]
<canvas debug="true" >
    <view>
        <view width="220" height="80" bgcolor="#eaeaea" clickable="true" 
focusable="true" >
            <text text="click and then press tab" />
            <handler name="onclick" >
                this.parent.destroy();
            </handler>
        </view>
    </view>
</canvas>

[2] it's lz.Focus, the nullpointer-exception is raised in 
"genMoveSelection(..)"

[3]
<canvas debug="true" >
    <handler name="oninit" >
        lz.ModeManager.makeModal(this.a);
        lz.ModeManager.makeModal(this.b);
    </handler>
    <view name="a" />
    <view name="b" >
        <method name="passModeEvent" args="e, v" >
            // side-effects of passModeEvent do occur in real 
applications, see LPP-7681!
            if (e == "onclick") v.parent.destroy();
            return true;
        </method>
    </view>
    <view>
        <view width="160" height="80" bgcolor="#eaeaea" clickable="true" >
            <text text="click here" />
        </view>
    </view>
</canvas>

[4] error in "LzNode#childOf(..)" through call from 
"handleMouseEvent(..)" in lz.ModeManager

> 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.
>
>
> ------------------------------