Re: Analyser reports memory leak… where?
Re: Analyser reports memory leak… where?
- Subject: Re: Analyser reports memory leak… where?
- From: Graham Cox <email@hidden>
- Date: Thu, 12 Sep 2013 19:41:52 +0200
On 12/09/2013, at 6:57 PM, Bill Cheeseman <email@hidden> wrote:
I appreciate your taking an interest Bill, it's always interesting to get a range of views. But:
> The point remains, however, that the getter that started this thread returned an object retained, and the caller therefore owns it and is responsible for releasing it.
There's an inherent contradiction in this statement. If it's a getter, then the caller has no responsibility for ownership of the returned object. If the caller does have that responsibility, then it's not a getter. In fact, -eventTypes in this case *is* a getter, or is intended to be.
> If the behavior of Analyze in this connection does still in fact change depending on whether you include "new" or similar terms in the method name, consistently with at least part of the Cocoa rule, one proper way to make the ownership of the object returned by -eventTypes clear would be to put "new" in its name.
Which would make it not a getter.
I think other contributors have actually got closer to the heart of the matter, which is that the getter calls the associated setter. That's probably a bad idea in general (certainly considering KVO, as Kyle pointed out, is very likely to cause an infinite loop), and I'm thinking that it should be a rule, that one does not do this. It could be that it's already an unwritten rule, baked into the assumptions made when the analyser itself was coded, and that's what's throwing it off. (Commenting out the setter line does make the analyser error go away). Normal getters, however they are coded with respect to the returned object, synthesized or whatever, do not call the associated getter, but as I said, this wasn't code I wrote. In fact, this particular module has been a constant source of pain since it was forced on me, but its days are numbered anyway.
--Graham
_______________________________________________
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