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 17:01:23 -0700
On Aug 8, 2012, at 4:52 PM, Graham Cox <email@hidden> wrote:
> I see that NSCopyObject is deprecated as of 10.8 (but is still being used internally).
>
> This is going to be fun moving forward :) I'm not sure how binary compatibility is going to be maintained as NSCopyObject disappears, for example, in a cell subclass I might have:
>
> - (id) copyWithZone:(NSZone*) zone
> {
> MyCell* copy = [super copyWithZone:zone];
>
> [copy->someInternalPointer retain];
> return copy;
> }
>
> This relies on the existing behaviour of NSCopyObject not retaining pointers it has copied.
>
> If in future NSCell changes to use some alternative such as the ARC stuff you mention, this will now leak due to the extra retain. If I don't do the retain, it will crash on older systems due to the (later) over-release.
It's possible that NSCopyObject will live on in NSCell forever due to binary compatibility constraints like you described. I don't know if there are other plans here.
> Is there a solution to this that will work forwards and backwards?
Use ARC in your subclass. Then you can write your subclass so that it doesn't care how the superclass is implemented.
This code works under ARC whether or not the superclass used NSCopyObject:
- (id) copyWithZone:(NSZone*) zone
{
MyCell* copy = [super copyWithZone:zone];
copy->someInternalPointer = [copy->someInternalPointer copy];
return copy;
}
--
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