On 01/12/2009, at 12:30 PM, Mario Kušnjer wrote:
> This could not be like this, right ?
>
> [cell image] = [image retain];
No, because [cell image] returns a value, it does not set a value. You might
consider doing this though:
[cell setImage:image];
Clark is right that if the copy was a bitwise copy, this is going to
over-release (or insufficiently retain, same thing), but assuming the presence
of a bitwise copy that is not explicitly documented as such is an assumption
too far.
The docs for NSCopying state that a copy can be implemented by:
• Implement NSCopying using alloc and init... in classes that don’t
inherit copyWithZone:.
• Implement NSCopying by invoking the superclass’s copyWithZone: when
NSCopying behavior is inherited. If the superclass implementation might use the
NSCopyObject function, make explicit assignments to pointer instance variables
for retained objects.
• Implement NSCopying by retaining the original instead of creating a
new copy when the class and its contents are immutable.
So doing this:
cell->image = [image retain];
is actually the safest thing to do, because it works correctly whether or not
the superclass used NSCopyObject, so no assumptions about the superclass
implementation has to be made. I still feel that NSCopyObject is a nasty
dangerous function though, and for my own classes I never implement copy that
way.
--Graham_______________________________________________
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
