RE: copyWithZone - if anyone could explain this to me ?
RE: copyWithZone - if anyone could explain this to me ?
- Subject: RE: copyWithZone - if anyone could explain this to me ?
- From: Jeff Laing <email@hidden>
- Date: Tue, 1 Dec 2009 05:57:09 +0000
- Acceptlanguage: en-US
- Thread-topic: copyWithZone - if anyone could explain this to me ?
> > 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@hidden)
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:
This email sent to email@hidden