Re: [Libxmlplusplus-general] API questions

[murrayc t-online de (Murray Cumming)]

On Mon, 2003-01-27 at 19:26, Stefan Seefeld wrote:
> Murray Cumming wrote:
> 
> > Nodes are created by their parents - other Nodes, or maybe the Parser,
> > and are owned by them. You shouldn't need to new a Node yourself. This
> > seems to work. We might state that more formally later.
> 
> well, the API suggests that I can create a node myself: all constructors
> are public.

The API is not yet stable. And I said "We might state that more formally
later". It's not perfect, but it's getting better.

> >>Imagine you have two xmlpp::nodes, with a parent/child relationship.
> >>Then you delete the parent,
> > 
> > 
> > You shouldn't delete nodes. Let libxml++ take care of that.
> 
> Can you elaborate on that a bit ? How (and when) does libxml++ care
> for node deletion ?

In destructors of the objects that new the Nodes. There isn't very much
source code to look at.

> All I see is a single node tree created at parse time, and deleted
> recursively in the parent (root) node destructor.

Yes, and those Nodes can also be created by add_child() methods.

> But what happens if I want to restructure the tree manually, i.e.
> want to insert new nodes, remove them, or put them into different
> parents ?

I don't know. Try.

> That doesn't seem to be supported at all right now. So it seems the
> current DOM tree should be considered read-only...

No. You can create nodes, remove nodes, and change details of nodes, all
without using new and delete.

> >> calling the underlaying libxml2
> >>cleanup function (which, let's say, cleans up the subtree recursively).
> >>Your child xmlpp::Node now points into invalid memory !
> > 
> > 
> > In general, if you can provide a test case that reproduces a bug, we
> > might investigate it.
> 
> as an example of the above, the Node::remove_child() deletes a given
> child node. There doesn't seem to be a way to really remove a child node
> and insert it elsewhere.

No, there is no way to move a child from one node to the other. But it
should be easy to add such a method if you like - e.g.
Node::reparent(Node child, Node new_parent).

Some more complex/smart memory management might be more pleasant, but
it's a bigger job that I'd like to leave until after we have provided a
simpler stable API in the meantime.

>  Or at least there isn't a way to do it without
> going the way of a deep copy.

By the way, Xerces-C++ has probably dealt with the same issues, so you
might like to investigate their code/archives.

> Now think about the following situation: libxml2 provides a way to 
> retrieve a 'NodeList' that match a pattern expression ('xpath') in the
> context of a given document. So it returns a list of xmlNode pointers.
> How can that be wrapped with libxml++ ? 
> You can't just put those xmlNode
> pointers into xmlpp::Node instances, as they would make a deep copy of
> the nodes,

Yes, that is a problem. The current libxml++ would tend to reimplement
the whole thing in C++. Obviously I'd like to avoid that.

>  which is probably not what you want.
> What would be much more appropriate is to create xmlpp::Nodes that refer
> to those xmlNodes without assuming ownership of them, so they can still
> be 'managed' by other xmlpp::Node instances inside the document tree.

But who would delete those C++ instances?

> On the other hand, if there was a way to map back xmlNodes (libxml2) to
> xmlpp::Nodes (libxml++), the pattern matching function could return 
> pointers to existing xmlpp::Node instances.

Yes, that would be nice, but I haven't found a way to do it. libxml
doesn't use GObject structures.

>  Well, this would, however, 
> still not address the issue about manipulating a document tree without
> making deep copies.

It might help a lot.

> I hope this illustrates why providing more flexible ownership semantics
> is important.

Yes, maybe. But it's not required for the current API. If it required
for extra API then fair enough. As I said before, I'd like to do it
anyway. But don't hold your breath for me to design, implement, and test
it. I'm working on libxml++ just to get at least a basic stable API.

> >>I would suggest you fix the semantics and then implement that
> >>appropriately, either by always using deep copies, or (probably better)
> >>by means of smart pointers (ref counting).
> > 
> > 
> > I feel like smart pointers could be better, but so far there doesn't
> > seem to be a big need. Maybe after the API freeze.
> 
> sure, if you plan a release, this shouldn't get into the way. However,
> I'm not sure that this important a point can be added later without
> affecting the API. Or, what's even worse, without affecting the semantic
> of an existing API.

The API will not stagnate just because we have a stable branch. API
changes will be even more possible in the development branch when we can
tell people to use the stable API if they don't like API instability.

> By the way, I'm just chatting with Daniel (DV) on
> irc://irc.gnome.org/#xml, and he explains that the '_private' field in
> the xmlNode structure could be used to implement the inverse mapping,
> i.e. to point back from xmlNode to xmlpp::Node.

Sounds great.

> This really means libxml++ can (and then should) use libxml2 pointers
> *everywhere*, even to access child nodes.

I would like that.

-- 
Murray Cumming
murray usa net
www.murrayc.com