discuss-gnustep
[Top][All Lists]
Advanced

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

Re: NSXML* classes


From: Gregory Casamento
Subject: Re: NSXML* classes
Date: Thu, 23 Feb 2012 12:48:26 -0500

Fred,

I see that Doug replied to the rest of it, I just have a couple questions...

On Thu, Feb 23, 2012 at 4:37 AM, Fred Kiefer <fredkiefer@gmx.de> wrote:
> 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.

I'm wondering why the current approach wouldn't work with GC or ARC.
Can you elaborate?

> 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?

I agree with this. In the case where one of the children is an
instance of a subclass which overrides isEqual: the check would not
behave as intended since it relies on the C library to do the work.

> 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.

The namespace implementation is currently not complete.   I'm aware of this.

Later, GC
-- 
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com



reply via email to

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