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
|
