On Wed, Aug 18, 2010 at 2:08 PM, Sherm Pendley <sherm.pend...@gmail.com> wrote: > The caller is doing nothing wrong here. It's finished using foo, and > released it. If the caller's only use of bar is within the scope of > the calling method, it's under no obligation to retain it. It's the > responsibility of -stringByReplacing... to return an object that > remains valid throughout the caller's scope, even if the original > string is released. Doing "return [[self retain] autorelease]" > fulfills that responsibility; "return self" does not.
Meh, this all boils down to caller vs. callee responsibility. I tend to think in terms of caller responsibility, but the documentation seems to prefer callee responsibility *except* in the case of collection classes or parent/child relationships: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html I suppose I should agree that not requiring the caller to retain an object for its own scope is preferable, but most of the times this issue pops up for me are in fact parent/child relationships. > Indeed, on that very page, at > <http://developer.apple.com/mac/library/documentation/cocoa/conceptual/MemoryMgmt/Articles/mmAccessorMethods.html#//apple_ref/doc/uid/TP40003539-SW6>, > it gives this example: It gives it as one example of three, the other two not having performing an immediate retain/autorelease pair. --Kyle Sluder _______________________________________________ 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
