On Sep 12, 2013, at 11:52 AM, Graham Cox <graham....@bigpond.com> wrote:
>> At it's core, that's what is really "odd" about the code. It uses a getter >> that does not comply with the getter convention. > > I believe it does. I think your reading of the getter convention may be > incorrect. If you can point to explicit documentation that states that the > returned object must belong to an autorelease pool, I'll stand corrected, but > that would be the first time I've ever heard that in 13 years of Cocoa > programming! I participated in a lengthy online debate about this very subject in 2002 with Apple's Ali Ozer and a bunch of other folks whose names are very familiar on this list. Opinions were all over the map. Eventually, as I recall, Ali Ozer won the debate by issuing a technote or Q&A about the proper way to write getters and setters. I just spent a little time looking for it but have not yet found it. As I recall, it stated that the "return [[x retain] autorelease]" pattern is preferred for getters and gave many reasons for preferring it. I understand that @synchronize generates getters that comply with this preference, and I also recall that some of the early documentation about properties discussed this convention. I did find a message from Ali dated July 31, 2002, at <http://www.cocoabuilder.com/archive/cocoa/50627-accessor-methods-and-auto-release-memory-trail.html> in which he states the autorelease preference. His message also said that a faster alternative when speed is paramount is to return the variable without retain or autorelease, and the code example he gave implied that the variable was retained (it was retained or copied in the setter and returned in the getter without modification). So I have to qualify what I said earlier today by noting that, in appropriate circumstances, getters can return retained objects instead of autoreleased objects, although the latter is preferred. 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. By the way, anybody interested in reading Apple's autorelease pool patents can go to the US Patent and Trademark Office Web site <http://patft.uspto.gov> and search for patents nos. 5,687,370, 6,026,415, and 6,304,884. Ali Ozer is listed as one of the inventors. Some of the historical and technical information in the patents is really interesting. The current statement of the Cocoa ownership rule is here: <https://developer.apple.com/library/ios/documentation/cocoa/conceptual/MemoryMgmt/Articles/mmRules.html>. It notes at the end that the rule is similar to but a little different from the Core Foundation "Create Rule." That, and the text of the Cocoa document, suggest that my assertion that the -eventTypes method we are discussing must be named with "new" is overstated because the Cocoa rule is different from the Create Rule. The Cocoa Rule says that you do own an object returned by a method having “alloc”, “new”, “copy”, or “mutableCopy” in its name, but it also spells out several other cases where methods without those names still make the caller the owner -- namely, by retaining it. Since the -eventTypes method does retain the object, the Cocoa document's statement of the Cocoa rule confirms that the caller of -eventTypes is in fact the owner of the object and responsible for releasing it. 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. Alternatively, apparently, you could continue to name it like a getter and simply document the method to indicate ownership. Either way, Analyze should not base its error reporting on the name of the method alone, because it is the Create Rule, not the Cocoa rule, that relies solely on names. So I am now once again puzzled by my discovery a couple of years ago that adding "new" to Cocoa method names removed the error reports. It appears that Analyze is enforcing a slightly different rule from the Cocoa rule, one that is more consistent with the Core Foundation Create Rule. -- Bill Cheeseman - b...@cheeseman.name _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
