Re: [Libxmlplusplus-general] API questions

[Stefan Seefeld <seefeld sympatico ca>]

Murray Cumming wrote:

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

ok, that may work if I really just want to move a child from one place
to another in a single atomic move. But what if I want to take it out
of the document (temporarily), put it back later, or even move it to
a separate document ?

The issue here seems really to be about memory management, not about
making the document manipulation API more rich.

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

Ok, as I said, this can certainly wait. I don't know your timeframes
for the next releases. But you were talking about API *stabilization*,
which made me worry a bit.

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

yes, I looked at their code, though a long time ago.

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

precisely. The current libxml++ Node types use strings, vectors, and 
other strict C++ classes as implementation. That's fine for a pure-C++
library. But if you want to provide a (possibly thin) wrapper around
libxml2, you may want to do it differently...

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

That depends on the ownership semantics. If xmlpp::Node objects are
shared pointers for xmlNode pointers, they are themselfs to be managed
by the application (the user). If they are, it would be best to use them 
on the stack whenever possible.

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

I don't know what GObjects have to do with it (and in fact, I don't
know what GObjects really are), but libxml has, as I said, a '_private'
member which could be used for that.

> > 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'm not waiting for anything. In fact, I think I'll just try to make the
changes I'm suggesting, and then see whether you like it enough to patch
your code with it.

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

Good !


Stefan