> > 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.
Ah, the penny drops. You're saying that the superclass might have used,
pseudo-codingly,
memcpy( newobj, oldobj, sizeof(typeof(oldobj)) )
rather than
memcpy( newobj, oldobj, sizeof(oldclass) )
and thus the newly created object *might* have essentially random bits in the
"subclass" instance variables. I was assuming it was always going to use the
latter - seems stupid to use the former under any circumstance. It's never
going to be valid for a superclass to make assumptions about the behavior of
its subclasses, and thus it's completely irrational to present them with an
indeterminate state, when it could just as easily promise "all your instance
variables will be nil".
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
