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

[P T Withington]

On 2009-01-26, at 18:24EST, André Bargull wrote:

> [Let's provoke some annoyance  :-P ]

Hah, hah, hah.

> Oh wait, you just said nothing in the LFC depends on the current way  
> things work. I really believed in you,

But wait, I said:

"where a child node _needs_ to access it's parent when the parent is  
in the process of being  deleted"

so, there may be cases where it _does_ access the parent, but does it  
_need_ to?  I don't think it does. So it is just a matter of fixing  
those cases to be careful.

So, how about if we analyze this proposal on two axes:

1) Would there every be a case where it would be _necessary_ to access  
a parent that is in the process of being destroyed, or is there an  
alternative action that would be safer and more efficient when the  
parent has been destroyed?

2) Is it an improvement to reduce the possibility that a node that is  
destroyed will never be garbage collected, because one of its children  
stores a copy of parent/immediate parent on the way to being destroyed?

Both of your examples remind me of the chainsaw user who cuts the  
branch he is standing on and then complains that the chainsaw did not  
prevent him from a horrible accident.  Are there really nodes that  
believe they can delete their own parent (knowing that will result in  
their own deletion)?

---

As an aside, one might ask why there is a need for 'delete' in a  
garbage-collected language at all?  'delete' was initially introduced  
into the language because it was discovered that by writing references  
to themselves all over the place (especially in delegates), nodes that  
fell into disuse were never collected, because there were still  
references to them everywhere.  Hence the need for delete to remove  
those references -- which this proposal intends to enforce on child  
nodes too.

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