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

[Thomas Broyer <tbroyer ltgt net>]

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
> casts).

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.

Tom.