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