Re: [Libxmlplusplus-general] parametrizing libxml++ for the character /string type

[Stefan Seefeld <seefeld sympatico ca>]

Murray Cumming wrote:

> Yes, but even in the unstable branch there's no point in applying major
> stuff unless we know it's going to work completely.

right, but it's one thing to know where to head, and another to check in
only stuff that completes a transition from the old to the new way of
life. Anyways, I share your worries, and I think I can come up with a
patch that doesn't leak (may be modulo some public methods that should
at least be declared 'deprecated' for the time being).

> Actually, _I_ started to think that we might even get this into 1.0 if
> it proves itself quickly enough.

ok.

> > Please let me know how you would like to proceed.
>
>
> Well the patch as it stands seems to leak C++ wrapper instances. That
> needs to be fixed - I like the idea of using the new libxml2
> notification stuff to that.

good. I'm looking into that. libxml2 provides methods 
xmlRegisterNodeDefault() and xmlDeRegisterNodeDefaults()

that have to be called to install the handlers. How should we do this ?
In a global (but hidden) object ? We must be sure that the handlers are
installed before the first xmlpp objects are created...

> > I have a long list
> > of things I'd like to submit / check in, and I'd like to get forward
> > as fast as possible (I'd like to use this in my own projects and at
> > work).
> >
> > Again, I can work out a switch of the implementation in a single atomic
> > patch, but that would imply changes to the API,
>
>
> What API changes are required?

As I said, for now we could just deprecate some methods, mostly
constructors. That's just to prevent users from creating unbound nodes,
as for unbound nodes the ownership rules would be the inverse: as nobody
ownes the implementation objects, they can only be deleted by the 
wrappers. The normal way would be to only have the 'Document' object
be the owner of the xmlDoc pointer, and let xmlFreeDoc implicitely
destroy the xmlNodes, and then, by means of said callbacks, free the
xmlpp::Node objects.

The fact that ownership semantics depend on the objects being bound or
not worries me a bit. We really ought to make clear how to work with
that, either by restricting the API not to allow the creation of unbound
objects, or by some other means...

> Let's consider creating a branch after that first patch is finished.
> Maintaining 2 branches is difficult so I'd like to postpone it as much
> as possible. Ideally branching happens after 1.0.0. But I don't want to
> delay your work either.

ok, thanks. I'll try to fix the patch today. In fact, I do think that 
all the proposed changes (well, possibly modulo the character trait
templating) are rather simple, thanks to Daniel's work on libxml2, so
it may all happen before 1.0.


> > Yet I tend to think that a new 'Document' type fits in here, as it is
> > consistent with the other changes that directly map between libxml2 and
> > libxml++ types.
>
>
> If you can do it without creating that class then it isn't necessary. Is
> there a libxml2 document "class"?

yes there is. Anyways, I'll try to do a minimal patch using the callback
stuff. Then we can see how to complete it with additional patches such
as a 'Document' class. By the way, 'Attribute' should really derive from
'Node'. But that, too, can wait.

> > The DomParser class now has a number of members, which,
> > with the new implementation would all be owned by a single Document
> > object (i.e. via _private members of the impl object...).
>
>
> Yes, I'd like to see this, but it seems separate (but dependent) to me.

Fine.

Stefan