[xml] Retrieving boolean/number/string value from XPath objects



Hi,
Today I started implementing EXSLT's extensions (http://exslt.org) and I
came to a reflexion I already had last fall while we were talking about
libxslt.

Why isn't there "basic" functions to convert values to
number/boolean/string?

I'm in the math:min() function of EXSLT. I receive a node-set as argument
and need to compute and compare the number value of each node.
To do that, I can:
 · create one new node-set for each node and use xmlXPathCompareNodeSets
   (or push the values on the stack and use xmlXPathCompareValues) and
   then convert one of the node-set to a number (as the return value)
 · create a new node-set object from the node, use xmlXPathConvertNumber
   (or push the value on the stack and use xmlXPathNumberFunction)
   and then retrieve the number value.
=> These lead to useless allocations/deallocations
 · use xmlGetContent and xmlXPathStringEvalNumber

I'm convinced there should be functions or macros to:
 · convert a "basic" value (xmlChar*, double, int, xmlXPathNodeSet) to
   another one (xmlChar*, double, int)
 · convert an XPath object to a "basic" type (xmlChar*, double, int)
and I can't understand why there aren't yet.
This would simplify other functions like sum() or even id() (and document()
in libxslt) and avoid useless allocations/deallocations in many programs
based on libxml or extension functions.

The current functions for casting XPath objects to XPath objects should
rely on these "low-level" functions.

The basic idea is to work on xmlXPathObject's only at the beginning (when
you receive arguments) and end (when you return values) of functions to
avoid allocations/deallocations and not-instinctive manipulation of
xmlXPathObject's.

Should I go for it or you disagree with such a refactoring?

Tom.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]