Re: NSXMLNode copyWithZone: is broken for Processing Instructions

[Fred Kiefer]

On 09.03.2012 01:02, Doug Simons wrote:
> One of your recent changes to NSXMLNode's copyWithZone: now causes
> the content of some nodes (processing instructions, at least) to be
> lost in the copy. The call to setObjectValue: is the culprit, as it
> in turn calls setStringValue: (with a nil value, at least in the case
> I traced through) which erases the content of the libxml node.

Thank you for this bug report. As always it would have helped to send 
along a test case that shows the problem. I tested on Mac and of course 
the object value gets copied when the node is copied. I also added more 
test code for the different node types, but there is nothing specific 
for processing instructions. It turns out that the problem seems to be a 
mismatch between the object value and the string value when nodes get 
created by parsing XML. Is this the issue you are talking about?

> I'm not sure what the motive was for your recent change, but take a
> look and see if you can resolve this problem.

Sorry, I may be in a bad mood at the moment, having to deal with Greg's 
pbxbuild revert, but this sentence sounds out of frame for me. What may 
have been my motive? Break your code? Make NSXMLNode unusable? Sorry, I 
really don't get you. For most of my code changes I added test code that 
shows that the previous code fails in some cases. I spend a lot of time 
in an area of GNUstep I am myself not that much interested, to make it 
generally usable and you ask about my motive?

Let us rather go back to the issue you seem to be having. The correct 
solution here would be to create the correct object value when we 
instantiate an NSXMLNode from an libxml2 node. This requires more tests 
on Apple, for which I don't have the time at the moment. (The problem 
here is that the object value may be nil when the string value is "") As 
a work around I changed the copy code to ignore the object value, if it 
is nil. This should resolve the problem for you and is not that wrong. 
If we ever fix the object value creation, then the copy code will still 
be correct.

As a result for all my failed attempts to reproduce your problem we now 
have test code for all the different types of NSXMLNodes and also the 
correct NSXMLNode subclass used for different libxml2 node types in 
_objectForNode:.