I've frequently wanted Group.removeChild(Node). But every time I've wanted this,
instead of O(n) searching on index so I could then call
Group.removeChild(int) -- and in the process expose myself to thread
conflicts -- I've added a BranchGroup above the node I might want to delete in
this manner, and then called BranchGroup.detach() in O(1).
For me, the effect of not having Group.removeChild(Node) has led to more
efficient design.
-----Original Message-----
From: J. Lee Dixon <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, August 01, 2000 10:28 AM
Subject: Re: [JAVA3D] detach() suggestion
>How about this, in addition to the existing Group.removeChild(index), we
>have Group.removeChild(Node). Then, the Group parent could search its
>list, find the node, and call .removeChild(index) on its own. Then, one
>step further, Node.removeFromParent() would just call
>parent.removeChild(this). Does this make sense?
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
