Re: [xmlroff] What changes to FoXmlDoc?

[Stefan S. <se...@sy...>]

Tony Graham wrote:

> The present process for creating an FoXmlDoc from a filename is long-winded:
> 
>       xml_doc = fo_xml_doc_new ();
>       fo_xml_doc_set_filename (xml_doc,
> 			       xml_file);
> 
>       fo_xml_doc_parse (xml_doc,
> 			libfo_context,
> 			&error);

I think it would be cleaner to have a single function 'fo_xml_doc_from_filename'
that subsumes the three functions above.

>       if (error != NULL)
> 	{
> 	  g_critical ("%s:: %s",
> 		      g_quark_to_string (error->domain),
> 		      error->message);
> 	  g_error_free (error);
> 	  exit (1);
> 	}
> 
> That's partly because in the GObject world, everything has a _new() function,
> so the filename is set after the FoXmlDoc is created.

One reason why I strongly dislike GObject. Having a 'default constructor'
seems error prone, since it requires multi-stage construction. If you have
to call three functions to create the document there are three points of
potential failure, which all need to be checked, instead of just one.

> Creating an FoXmlDoc from a buffer would really be a wrapper on xmlReadMemory:
> 
>    xmlDocPtr	xmlReadMemory		(const char * buffer, 
> 					 int size, 
> 					 const char * URL, 
> 					 const char * encoding, 
> 					 int options)
> 
> Where 'options' would be extracted from settings in an FoLibfoContext and the
> rest would be set explicitly.

For symmetry, I'd add a 'fo_xml_doc_from_memory' function for this.

> The short form of my question is, is it better to:
> 
>  - Make separate 'constructors':
> 
>       fo_xml_doc_new_from_filename (...)
> 
>       fo_xml_doc_new_from_memory (...)

Yes !

>  - Make separate subtypes:
> 
>      fo_xml_doc_memory_new ()
> 
>      fo_xml_doc_file_new ()

I'm not sure I understand what 'subtypes' is referring to here. What
is the return type of these two functions ? Wouldn't it be the same ?
Why would the generated type care for whether it was created from
file content or memory ?

>    that each have their own _set() functions for their disparate parameters
> 
>  - Parse on 'construction', such that the fo_xml_doc_parse() function is no
>    longer required

Yes ! The more compact the API becomes the less it is error-prone, since
there are less check-points to watch.

Regards,
		Stefan