On Wed, Aug 8, 2012, at 04:52 PM, Graham Cox 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.
This might be a better discussion for objc-language, but I can envision
a future version of the language prohibiting implementations of
-copyWithZone: if ARC is enabled, in favor of some new selector.
Since most of the code in -copyWithZone: is copying ivars anyway,
perhaps we can take advantage of ARC and change the paradigm to reduce
the number of bugs created by forgetting to copy an ivar. I can see ARC
taking care of copying all ivars (performing the appropriate retain
semantics), and then subclasses would implement a selector like
-awakeFromCopy: to perform post-copy customizations (like unsetting
ivars that shouldn't have been carried over from the source object).
--Kyle Sluder
_______________________________________________
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
