On Aug 8, 2012, at 4:52 PM, Graham Cox <graham....@bigpond.com> 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 gpar...@apple.com Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
