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

[Steve Ball <Steve Ball zveno com>]

Sean McGuire wrote:
> Luca Padovani wrote:
>> [...]
>> 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?)
>>
> If I understand the alternate suggestion, doesn't it also risk breaking 
> binary compatibility and making every node slightly larger?

Every suggestion so far would break binary compatibility
and make the node slightly larger.  If we *don't* want either
of those to happen then application writers will have to
keep track of libxml2 nodes using a hash table (hashing off
the 32/64 bit pointer) (a possible exception being ObjC).

BTW, a little while ago I sniffed through the Python interface
code to see how it handles mapping libxml2 nodes to Python objects.
As I recall, the interface does *not* attempt to maintain a
backward pointer (from Python object to libxml2 node).
Every time a libxml2 node is referenced a new Python object
is created.  Is that correct?

Cheers,
Steve Ball

-- 
Steve Ball            |   XSLT Standard Library   | Training & Seminars
Zveno Pty Ltd         |     Web Tcl Complete      |   XML XSL Schemas
http://www.zveno.com/ |      TclXML TclDOM        | Tcl, Web Development
Steve.Ball@zveno.com  +---------------------------+---------------------
Ph. +61 2 6242 4099   |   Mobile (0413) 594 462   | Fax +61 2 6242 4099