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

Le 11/05/01 15:19:23, Daniel Veillard a écrit :
I usually do most of those "in-situ" in the allocated XPath object
being passed (this is the case I think for the most simple XPath

Well, in fact this is not true. xmlXPathConvert* functions always allocate
a new object except when nothing has to be done (for instance,
xmlXPathConvertString being passed an XPATH_STRING object)

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

  No it's a good idea, try to preserve the semantic of the existing
operation (including numbers ones ;-)

The xmlXPathConvert* functions are badly designed IMO (if the purpose is to
convert on place, there should be better to pass a pointer to a void
function, functions with the same prototype as current xmlXPathConvert*
functions not freeing their argument should then exist).
I won't modify this without your consent (these are "young" (lately added)
functions and such changes should impact many)

This is also the case of xmlXPathCompareNodeset*. They shouldn't rely on a
context (comparison is really context independant) and should receive
xmlXPathNodeSetPtr instead of xmlXPathObjectPtr as argument(s).
In fact, xmlXPathCompareValues should rely on these functions, curretly
it's the opposite.
I'll change that, without modifying the prototype in a first step but this
should be better IMO.

These are the two "big" unconsistances I see in the current implementation.
Not serious, just a bit... strange.


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