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: Fri, 24 Feb 2012 10:37:15 +0100

Am 23.02.2012 um 19:09 schrieb Richard Frith-Macdonald <address@hidden>:

> 
> On 23 Feb 2012, at 17:48, Gregory Casamento wrote:
> 
>> 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 <address@hidden> 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?
> 
> I may not be thinking the same thing as Fred, but I'd like to jump in here 
> and say that -retainCount is deprecated and does not work in GC or ARC, and 
> you can't do anything in -retain or -release either.
> I'm not sure what the correct ownership model is for a tree of nodes, but 
> it's fairly clear that the current code at least needs some change to avoid 
> using retain counts.

I think for now the solution could be to just #ifdef out all these methods for 
the ARC and GC cases. We may also need to use a special type cast when setting 
the private pointer of the libxml node for ARC. David surely could hep here.


reply via email to

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