Getter is pretty ordinary
-(id<RKTableViewDelegate>*)delegate
{
return _delegate;
}
So in this case A has a strong reference to B and is B's delegate, fairly
common pattern. A is now being deallocated and as part of that the delegate
relationship is being broken, one of two ways, either in A's dealloc it calls [
B setDelegate:nil ] or it just waits for B's dealloc which happens as part of
its own and B cleans up any delegate. In this case A was actually calling it
explicitly because I prefer things which set things up, to clean them up, I
like to see the pairing, but either is fine. In the setter, or rather in a
factored out method called in the setter, I had the
self.delegate == delegateArg
line. Indeed, as you say, the getter of delegate was causing the current value
of delegate (which is still A at that point) to be re-retained (not self).
There was no real good reason to have done that, using _delegate == delegateArg
is just as good, doesn't call the getter and doesn't retain/autorelease the
return value and if I hadn't factored the code out into another method, but
left it in the setter, I would have used the iVar directly for that reason.
I'm assuming ARC adds the retain/autorelease to stop the return value of the
getter being released before the caller gets it (section 3.2.3 of the ARC
spec).
On Dec 25, 2011, at 2:19 AM, Matt Neuburg wrote:
> On Sat, 24 Dec 2011 13:35:07 +0800, Roland King <r...@rols.org> said:
> object being dealloced. This line of code
>>
>> return self.delegate == delegateArg
>>
>> caused self to get a retain/autorelease, resurrecting the object. The change
>> to use the ivar directly fixed it
>
> Using the ivar directly is also a way of using self (saying "delegate" is
> just a way of saying "self->delegate), so it isn't the mention of self that's
> the problem; it's probably that the delegate property has a custom getter
> doing some weird stuff. If so, that's a thing to beware of; getting sneaky
> with accessors is a way to trip oneself up later... I'd examine that getter
> if I were you. m.
>
> --
> matt neuburg, phd = m...@tidbits.com, <http://www.apeth.net/matt/>
> A fool + a tool + an autorelease pool = cool!
> Programming iOS 4!
> http://www.apeth.net/matt/default.html#iosbook
_______________________________________________
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
