[email protected] [mailto:[EMAIL PROTECTED] Wrote:
>>The meta issue here is that I think this is a very confusing implementation >>for C++ programmers -- most would think that a DOMString is more like the >>typical C++ string class (std::string, for example), rather than a Java >>StringBuffer. I predict this will be a frequent source of >>very-hard-to-find bugs. Imagine geting a value from a node and >>inadvertantly modifying that string: >> >> DOMString theNodeName = node.getNodeName(); >> >> theNodeName += "foo"; >> >>I've now changed the name of the node. Looking at the code, that seems to be what it does since NodeImpl::getNodeName (and ::getNodeValue) does not clone before returning. I can't see that as being desirable or what the DOM group intended. Either the function should return a const DOMString& or clone first and do it consistently. Const'ing would seem to be the better approach. Is this something well known and accepted? Would the same effect happen in Xerces-J? Inquiring minds want to know. p.s. Has anyone set up a test harness in JavaSpec or similar for either xerces parser.
