GNOME Bugzilla – Bug 668980
Make it possible to create a Document object from an xmlDoc*
Last modified: 2012-08-10 11:03:25 UTC
Currently the Document(_xmlDoc* doc) constructor is private, but accessible to DomParser and SaxParser through the 'friend'. This makes it not possible to implement alternative parsing strategies beside DomParser and SaxParser. It would be nice to have the Document constructor public, or to have a protected method of Parser (like Parser::create_document_from_cobj) usable to access it from derived classes. My specific use case it implementing a RecoveryDomParser class that is more tolerant to non well formed documents,
OK. I have made it protected in this commit: http://git.gnome.org/browse/libxml++/commit/?id=4a71a9a74affadbc4a6f779f3fa86ca0e30e7a35 I don't know how much we want to support the idea of derivation, but feel free to try. If you need more changes, maybe you could attach a patch. Thanks.
Created attachment 207658 [details] [review] Patch to expose Document constructor to any subclass of Parser Sorry for the delay. I was actually thinking about something like this: This provides a protected Parser::create_document_from_cobj that can be used to allocate a Document (using it's private constructor) by any subclass of Parser. This also reduces the amount 'friendness' required in Document, since now only Parser is friend of the Document Class, while currently both DomParser and SaxParser where.
Isn't this unnecessary now that the constructor is protected?
Well, even if the constructor is protected it cannot of course be used by classes derived from a friend class. The solution would be to define a subclass of Document just or the purpose of accessing the protected constructor and this seems suboptimal to me. Moreover, I don't see any point in deriving Document to change it's behavior, while it looks very reasonable to derive Parser, since it's the class that creates and define the properties of the libxml context. I think that the solution I proposed fits better in the current code while making it possible to write meaningful extensions in proper object oriented style
Sorry to inquire again about this. Is there any chance that the patch or something similar in spirit may be accepted?
OK. I guess that using Document to wrap an arbitrary XmlDocument should not be too weird. I would prefer to just make the constructor public, with enough documentation about how the C object will be managed/owned.
Created attachment 220805 [details] [review] patch: Document: Make the Document(xmlDoc*) constructor public. There are similar public constructors in many other classes. Some examples: Dtd(_xmlDtd* dtd); explicit Schema(_xmlSchema* schema); explicit Node(_xmlNode* node); and all classes derived from Node. Would it be an API/ABI break to make Document(_xmlDoc* doc) explicit? E.g. can an added 'explicit' change its mangled name? libxml++ can be built and checked (make check) with and without 'explicit'.
(In reply to comment #7) > Would it be an API/ABI break to make Document(_xmlDoc* doc) explicit? Not a very serious one, particularly as it was protected. Feel free to push, and thanks.
Pushed with a public explicit Document(_xmlDoc* doc) constructor.