- From: Eric Vasilik <ericvas@microsoft.com>
- Date: Tue, 26 May 1998 23:12:53 -0700
- To: www-dom@w3.org
>>The spec could be read to imply that Node insertion passes ownership to >>the containing node and removal/replacement returns ownership to the >>caller. Is this a reasonable interpretation? > >That might be a reasonable approach, but I know that *I* never wrote >anything into the spec with this thought in mind. Can you point to a >particular bit of the spec that needs clarifying? I think it is implicit that node insertion passes ownership to the tree/parent-node regardless of the language or memory management being used. It is unreasonable for a DOM user to maintain references to all nodes inserted into a given tree such that the user is required to explicitly delete/release all the inserted nodes when the tree/parent-node is deleted/released. When the tree/parent-node is deleted/released, assuming there are no remaining references to any children, all those children will be inaccessible (because the only way to get to them was just deleted/released) and the user will have no way to otherwise delete/release them. The tree/parent-node must, then, delete/release them to not have working set bloat or a memory leak. Actually, as I write this, I'm wondering if it is possible to implement the DOM without using a reference counting model. Above I said that the parent node must release/delete any children. If a non-reference counting model is used, how is the parent to know to delete a child or not? Perhaps I have spent too much time writing apps which use reference counting! Can anyone address a memory management scheme (other than garbage collection) for the DOM where reference counting is NOT used which addresses the example above? - Eric
Received on Wednesday, 27 May 1998 02:11:31 UTC