[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
- NSXML* classes, Ivan Vučica, 2012/02/18
- Re: NSXML* classes, Gregory Casamento, 2012/02/20
- Re: NSXML* classes, Ivan Vučica, 2012/02/20
- Re: NSXML* classes, Gregory Casamento, 2012/02/22
- Re: NSXML* classes, Fred Kiefer, 2012/02/22
- Re: NSXML* classes, Niels Grewe, 2012/02/22
- Re: NSXML* classes, Gregory Casamento, 2012/02/22
- Re: NSXML* classes, Fred Kiefer, 2012/02/23
- Re: NSXML* classes, Doug Simons, 2012/02/23
- Re: NSXML* classes,
Gregory Casamento <=
- Re: NSXML* classes, Richard Frith-Macdonald, 2012/02/23
- Re: NSXML* classes, Fred Kiefer, 2012/02/24
- Re: NSXML* classes, Ivan Vučica, 2012/02/26
- Re: NSXML* classes, Fred Kiefer, 2012/02/26
- Re: NSXML* classes, Fred Kiefer, 2012/02/26
- Re: NSXML* classes, Ivan Vučica, 2012/02/26
- Re: NSXML* classes, Fred Kiefer, 2012/02/27