Sent from my iPhone
On Nov 30, 2009, at 17:26, Jeff Laing <jeff.la...@spatialinfo.com>
wrote:
In most cases, yes. However, copyWithZone: is special, the
superclass'
implementation just blindly copies all of the raw bits in the source
object to the newly created one. If you were to use the normal
-setImage: call, that old value would be released one too many times.
Assigning to the instance variable in this case is the way to avoid
that.
Why would you not just do:
[cell->image retain];
That makes it a lot clearer to me - since it was a bitwise copy,
cell->image and image are identical values whereas the assignment
looks like you are changing something.
Because it may *not* have been a bitwise copy. The superclass may have
either done a bitwise copy of the whole object (the common case, I
believe) or it may have only copied its *own* instance variables (in
which case, cell->image will be nil). It's because of this uncertanty
of which method the superclass uses that this, admittedly ugly, bit of
code is used.
Generally, this is only an issue for people implementing copyWithZone:
on an object that does not inherit directly from NSObject.
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
