Re: What would you like to see in XML::LibXML ?

Aristotle Pagaltzis <[email protected]> wrote:
> * Shlomi Fish <[email protected]> [2012-01-29 21:15]:
>> One option to overcome this may be to
>> make these annotations be “tokens” which are arbitrary perl strings
>> or numbers, but not arbitrary perl scalars. The XML-LibXML programmer
>> will be able to map or unpack these tokens into something more
>> complex, but it would be their responsibility to allocate unique
>> tokens and to free their resources later.
>
> that manages to just barely allow Aaron’s use case at all, but it does
> not make it possible to do it solidly, much less do it with a semblance
> of convenience.

The approach Shlomi suggests would be (just) sufficient for my
purposes, though in some cases where I currently fake this with
attributes, making use of it would require using the actual node
annotation as a key in an out-of-line (or inside-out–style) hash (as
with Tim Brody's suggestion of using overloaded stringification to
extract a stable per-node value to use as a key).  That in turn would
require restructuring the relevant code to store the out-of-line hash
in a place where everything that needs it can find it.

If the out-of-line-storage approach were the only one we could rely
on, I think I'd rather be able to ask XML::LibXML to generate a unique
token for each node in a document, rather than having to come up with
one myself.  (Especially since the underlying node pointer is readily
available in the XS parts of the implementation, and could (I believe)
be used to generate a stable scalar token automatically.)

But I do think it would be better to be able to attach data directly
to a node — and ideally under a programmer-chosen name, so that
multiple CPAN modules could each use this feature on a single document
without getting in each others' way.

> Aaron may feel differently about this, but to be honest, if this is your
> final offer (so to say), then I would rather prefer that the feature not
> be added at all than tie up the _private slot and stunt the possibility
> of a more a elegant interface in the future.

Well, as long as the only advertised interface to this is a Perl-space
method on nodes, it would presumably be possible to later change the
storage implementation, and offer an additional method which does
something else.  Then the obvious disadvantage is that there'd be two
features which are obviously related, but with annoying differences in
how they can be used.

-- 
Aaron Crane ** http://aaroncrane.co.uk/
_______________________________________________
Perl-XML mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs