On Sep 4, 2007, at 17:09, TRANS wrote: > On 9/4/07, Dan Janowski <[EMAIL PROTECTED]> wrote: >> I did a little testing of << against my own application and found an >> incompatibility. >> >> << now copies a node/tree before adding it to another. I had code >> that added the node to a tree and then modified the node. This >> modified the original and not the copy in the parented tree. I don't >> see this as a problem, and the ruby code (in my app) seemed kinda >> dumb to do it that way. >> >> There may be a way to modify the behavior, and I wanted to know if it >> makes sense to do so: >> >> When a node/tree is parented and it is the top node (no other parent) >> and not part of a doc, then it can be installed in place without >> copying, and the original node is modified as it is now a child. If >> it is an intermediate node, then it is always copied. >> >> --or-- >> >> since this is variable behavior that may not be obvious, maybe we >> disallow (raise) << for nodes that are part of other trees? This may >> break even more things though. >> >> The copy feature when a node is a non-doc root, could be made >> optional. Either way the behavior changes. Should there be a warning? > > A bit more general of a question... If it's being copied how does one > maintain a reference too it? > This problem is a result of ruby's = and << operator, ruby forces the return to be the rhs input in the former and the lhs in the latter. I think the best way to handle it is to make the exact same function available as, say, node.add_child(a_node) => if (a_node.parent==nil?) ? a_node : copy (a_node)
A regular function being able to have a useful return value. > So unless I'm missing something, your second choice makes more sense. > There should be a way to detach a node from it's tree, even after one > has referenced it, and copying a node of course makes the copy in a > detached state. > Yes, the copy clears the attachments and none of the existing ruby references to deeper in the tree carry forward either. In other words, the ruby reference to the top node of the copy is the only ruby tie at copy result. > Of course, I'm no expert on the internals of libxml, but from a > high-level perspective that seems the most intuitive approach to me. > > T. > _______________________________________________ > libxml-devel mailing list > libxml-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/libxml-devel _______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
