[xslt] Re: libxslt effects on _private member of libxml structures

[Luca Padovani <lpadovan cs unibo it>]

Hi,

the mechanism suggested by Steve can be generalized further and in fact
DOM Level 3 (which is still a working draft) provides for it. You can
attach arbitrary objects to a DOM node, each object being associated to
a key. Different applications wishing to attach data to the same node
are supposed to use different keys. This would be of course slower than
array access, but in my experience I never had strict time constraints
on the extra-data.

The other possibility (with the hash-table) doesn't seem to me _that_
bad, assuming the associated data is sparse. Being the key the pointer
to the libxml2 node, the hash function would be very quick.

On Wed, 2003-03-26 at 10:39, Sean McGuire wrote:
> comments currently state it is, and add another field for holding the 
> key() value for libxslt.

I fear this would break binary compatibility, and would make every node
slightly larger (aren't they too large already?)

>   I'd prefer this, one reason being that it 
> limits the changes to libxslt, rather than everyone who has used the 
> _private field for their own application-specific data.

BTW, I'm still not totally convinced that XSLT key()'s cannot be
implemented efficiently otherwise, but of course I have to look at
Daniel's code before commenting on this further. Does anybody else share
my suspect or you all agree there's no other way of doing it?

-- luca