Re: NSCopyObject is a disaster (was Re: Another NSOutlineView issue)
Re: NSCopyObject is a disaster (was Re: Another NSOutlineView issue)
- Subject: Re: NSCopyObject is a disaster (was Re: Another NSOutlineView issue)
- From: Greg Parker <email@hidden>
- Date: Wed, 08 Aug 2012 16:39:06 -0700
On Aug 8, 2012, at 4:21 PM, Graham Cox <email@hidden> wrote:
> On 09/08/2012, at 9:10 AM, Graham Cox <email@hidden> wrote:
>> Ah, I'm thinking this *could* be due to my previous observation about cells being copied using NSCopyObject. If the cells are copied during that animation for some reason, then perhaps the text settings for my custom cell are not being copied, since I'm alloc/initing a new cell in copyWithZone: instead of relying on super's implementation. I'll follow along with that line of thought....
>
> Yep, that seems to be the issue.
>
> This opens up a whole big can of worms about implementing copy.
>
> If a superclass implements copies using NSCopyObject, then any pointer ivars we add in a subclass need to be additionally -retained. But if the superclass implements copy by alloc/initing a new object and setting properties, then this extra step would lead to an over-retain and so leak.
>
> But how can we know what approach the superclass has taken? It's not documented and we don't have the source. Aren't we supposed to be immune from implementation details like this? Or is it just a case of after a while the experienced Cocoaista "just knows" what to do in each case? This is only just rearing its head for me after almost 10 years...
NSCopyObject() is ugly. Avoid it if you can.
NSCell uses NSCopyObject. I don't know if there are other framework classes that are likely to be copied and subclassed that use NSCopyObject.
One solution is to compile your subclass with ARC. ARC-compiled ivars get correct retain count management inside NSCopyObject. (You still need to override -copyWithZone: if you want those ivars to be copied instead of retained, though.)
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden