discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSXML* classes


From: Fred Kiefer
Subject: Re: NSXML* classes
Date: Thu, 23 Feb 2012 10:37:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1

On 22.02.2012 20:45, Gregory Casamento wrote:
There are unit tests for the XPath code, but it's only one or two
cases.   I need to build out the test cases to more thoroughly test
the code.

Anyone else who is interested should (if they would like) also put
more cases in the make sure we have full coverage.

What I was looking for was a specific example that shows the need for the current retain count handling. We can only touch this, if we know about the problems we try to solve here. I don't like the current solution too much, as it wont work with GC or ARC, but wont touch it until we have enough test cases that show that an alternative solution is actually working.

While cleaning up the code I found a few issues that I would like to discuss here. One is the isEqual: method on NSXMLNode, the current implementation also checks the siblings of the node, which is obviously wrong and easy to solve (Just iterate over all children). But I would like to change the whole implementation here. Instead of going to the libxml2 structure for the test, I would like to implement it on the Objective-C level. The benefit would be that sub-nodes can easily override the check. Any opinion on that?

The next thing I found is that the whole namespace handling on NSXMLElement looks wrong. The structure element "ns" isn't present in xmlElement, we only have it in xmlNode. And even there it has a completely different meaning. Also I think that namespaces are a tree concept, not just a node or element one. You always should get the aggregated namespaces of all parent nodes. Anybody out there, with a deeper understanding of this issue? Otherwise I just start to write test cases on Cocoa and try to reimplement that behaviour.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]