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? 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. 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
