Re: [libxml++] Proposition: nodes manipulation

[Christophe de VIENNE <cdevienne alphacent com>]

Murray Cumming a écrit :

> On Sat, 2004-05-29 at 12:26 +0200, Christophe de Vienne wrote:
>  
>
> > Hi,
> >
> > I'd like to discuss a possible improvement of the API.
> >
> > To illustrate my idea I'll take the example of the Element class, but 
> > all nodes are concerned.
> >
> > Currently, the lifetime of nodes is controlled by libxml2, via callbacks 
> > on node ceation/deletion. The restrictions are that we cannot create a 
> > standalone node, nor detach and then delete a node like a normal class 
> > instance.
> >    
>
> It might be worth a try. I'd be happy to help test a patch.
>
>  
>
> > I think there is a solution which, without breaking the current 
> > behavior, would permit such things. I describe the deletion first 
> > because it's more simple.
> >
> > 0. Example
> > With this modifications we could something like :
> >
> > Document doc;
> > // ...
> > Element * e = <any node of the document>
> > e->detach();  //  detach the node from the tree
> > e->attach( new Element("achild") );
> > delete e;
> >    
>
> I'm not sure what's happening here. First we detach the element from
> it's tree, so there is no object that owns it, so we need to delete it
> ourselves, right?
>  

Right. Although the correct name for "detach" would be "unlink", as it's 
the name used in libxml2 for this action.

> But then you seem to reattach it to another parent that you new, but
> that you don't delete. I would expect e->attach() to give ownership of e
> to a new parent, so that "delete e" would not be necessary as long as
> the parent was deleted somehow.
>  

The function name is not clear. In fact I should have write e->addChild( 
new Element("achild") ), as you suggest in the next §.

> Maybe "new Element("achild")" is meant to be a child of e, so that both
> are deleted when you delete e. But, for that I would expect something
> like Node::add_child(Node* node), with documentation saying that it
> takes ownership of the node. 
>
>  

Indeed.

I think we can even implement a smart node pointer from all of this. As 
long as a node is linked to other nodes (other than children), we'd 
consider it's owned by it's tree. If a smart_node_ptr is the only 
pointer to a node and this node is not linked to any parent, then it 
would delete it in it's destructor. It's an almost classic reference 
counting, with the difference that a link to a parent is considered a 
reference.
I started to work on a patch which demonstrate what I first proposed, 
I'll try to include a proof of concept for smart pointers. Note that 
although it's technically possible, I think we should discuss the 
utility of such a feature.


Christophe