xerces-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david_n_bert...@us.ibm.com
Subject Re: Append Child, Insert Before, Remove Child, and Replace Child
Date Tue, 04 Nov 2003 19:33:10 GMT

> Actually I had already read that and found it to be somewhat ambiguous.
> Method: Append Child
> Adds the node newChild to the end of the list of children of this node.
> the newChild is already in the tree, it is first removed.
> Parameters:
> newChild of type Node
>       The node to add
>       If it is a DocumentFragment object, the entire contents of the
> document fragment are moced into the child list of this node.
> Return Value
> Node.  The node added.
> I read this to mean that the method simply returns the EXACT same node
> was passed in as the newChild.  Which leads to my question.  If the exact
> same node is returned...then why is there a return value at all?  Is it
> simply as a convenience for programmers?  This poses something of a
> for me as I am introducing this behavior into a graphical environment
> return values are handled differently and can't be stacked like they can
> a text based environment.

The recommendation does not guarantee that the node returned is the exact
same node as the one you passed, although it guarantees that
Node::isSameNode() is satisfied.  In practical terms, I can't imagine the
Xerces-C implementation would ever return anything other than the node you
passed in.  Perhaps you can use an assertion to verify that during testing,
or even have a run-time check that panics is that's not the case.


To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

View raw message