Sorry for the delay, job has kept me quite busy this week.
On Wed Jul 19 10:36:54 2006, cmccutcheon@oneil.com wrote:
Show quoted text> Going slightly out of my way to get the twig out of scope is the
> simplest way I can demonstrate what happens when an XML::Twig root is
> passed to a function (such as, a recursive function). Or, when you do a
> copy of a root node (in preparation for some destructive testing) and
> try to run an XPath on the copied node (with or without the original
> twig in scope).
If you pass nodes (root or otherwise) to a function, you just have to
make sure the twig itself is still in scope somewhere. If you want to
copy the root node, then I will provide a copy (or clone) method for a
twig so you can play with it to your heart's content. In the meantime
you can write your own, just create an empty twig and attach the copy of
the root node to it:
# $twig is the original twig
my $root_node_copy= $twig->root->copy;
my $new_twig= XML::Twig->new;
$new_twig->set_root( $root_node_copy);
Show quoted text> As for having XPath queries which begin with a leading "/", think of a
> tree walker that can get an instruction to go to any point on the tree
> from any point on the tree. And yes, I can see your point about using
> an XPath with a leading "/" from an arbitrarily deep node (I still think
> the root node should be an exception to this though).
I thought about making an exception for the root node, but really, in
all XML models I know, the document node and the root node are 2
different nodes, which really makes sense (the document node can have
the XML declaration, or a DTD attached for starters).
Show quoted text> Speaking of going from any point to any point, attached is a proposed
> patch for the XML::Twig->xpath method. The key difference is the
> ability to say something like this:
>
> my $xpath = $first_node->xpath($second_node);
>
> and get the XPath from the first node to the second node. Also, (for
> backward compatibility) if no second node is passed in, the output is
> identical to the original ->xpath method.
This is quite different from the original xpath method, and seems to me
quite specific to your code. You could subclass XML::Twig (and
XML::Twig::Elt, look at the elt_class option:
http://xmltwig.com/xmltwig/twig_dev.html#METHODS_XML_Twig_new_elt_class)
and either use the method in your patch, or one with a different name.
Show quoted text> As for the problem at hand, how is this for a possible solution?
> Instead of (or in conjunction with) creating a better error message
> (which would help), why not allow the use of Scalar::Util (and WeakRef)
> to be user configurable with something like:
>
> XML::Twig->new(memory_management => 0);
>
> and the corresponding method:
>
> $twig->set_memory_management(0);
>
> where the default would be "memory_management => 1". In conjunction
> with this change, the write-ups for ->dispose and ->delete would need a
> little more prominence in the documentation. (Although, I would vastly
> prefer the ability to use ->findnodes from arbitrarily deep nodes (with
> or without the original twig in scope).)
The thing is, all you have to do to avoid the problem, is not have the
twig go out of scope. Having XML::Twig test an option for each element
during parsing seems like a pretty sub-optimal solution to this.
Really, I don't quite understand why you NEED to drop the twig in your
code. It's not like it's a huge object, compared to the tree. It's not
small, but it has a fixed size, a few Kb at most.
__
mirod