You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by da...@us.ibm.com on 2003/11/04 20:33:10 UTC

Re: Append Child, Insert Before, Remove Child, and Replace Child




> 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.
If
> 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
that
> 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
problem
> for me as I am introducing this behavior into a graphical environment
where
> return values are handled differently and can't be stacked like they can
in
> 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.

Dave


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