... and of course the getter is
-(id<RKTableViewDelegate>)delegate .. no *, writing on my iPhone on the subway,
can't copy the code from my mac directly.
> 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/rols%40rols.org
>
> This email sent to r...@rols.org
_______________________________________________
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
